I have a webpage which runs a full static nuxt.js app. After a redeploy we sometimes experience some weird 404s, where payload.js was not found (404).
See the last two errors:
Could it be that some weird caching is causing this?
The problem appears (at least so far) only for users who visited the page, then a redeploy happendend, and after that they would see a failing page, because some js files were obviously missing...
I am very glad for any hints, why this could accur.
Are there some specific nuxt caching settings, I could improve?
Deploys are via netlify.com. But any caching there is disabled.
I thought caching should no be a problem because of the build number in the file url...
Thanks a lot and cheers.
Related
I'm trying to build a Vue web app and a friend was using it when it froze. Refreshing the page or opening a new tab and going to the page didn't fix it, and it would just keep loading until chrome said the page was unresponsive.
I thought it might be a network issue on their side but it works fine on their phone. Then I thought maybe there was a localStorage or cookie corruption issue, but then it was still broken on a different browser(chrome & edge).
https://i.stack.imgur.com/CTLTs.png
https://i.stack.imgur.com/zbjdr.png
This site doesn't seem to show any HTML and upon reload, nothing pops up in the network tab.
https://i.stack.imgur.com/zjqrk.png
The site uses vue3, vuex, fullcalendar, fontawesome, lzutf8(compression algorithm package). It's hosted on netlify.
Honestly, I don't even know where to start debugging this since I can't reproduce the issue on my computer and it makes it worse than I don't physically have the laptop in front of me. Here are some issues I think it may be:
There is some corrupt data between chrome and edge that's causing the site to freeze
I'm using a compression algorithm package to compress the vue store into a copy/pastable string. It's possible this is causing the site to slow when vuex tries to load the getter for the compressed store, but if the localstorage is empty all it has to compress is empty arrays so I don't see how compression would cause an issue.
A firewall on the device could be blocking the website
Maybe there's a chance Netlify could be blocking the site?
Potentially there's some issue with vue or vuex that I don't know about?
Here's the github repo: https://github.com/ZombiMigz/cpp-scheduler-webapp
and the website is deployed here: https://cppscheduler.com/
Any help or ideas would be greatly appreciated
My app is created in next.js and works great in localhost. When I deployed it in heroku, only the front page shows up and all page paths do not work even though they are correctly inputted in the browser. The only page that is connected to the index.js file in my page paths is the front page. Do the other pages need to also be connected to the indec.js file? I am terribly lost with this issue since the site works perfectly in localhost. In heroku every page path besides / has a 404 error. I didn't add any code to this question since no one file seems relevant to the issue. I've been searching all over for an answer to this issue but can't seem to find any relevant information online since the app is deployed successfully it just won't render any file paths besides /.
Thank you in advance for any help you can offer. I really appreciate it!
Applications are ran differently on localhost and when deployed to the server. Since you added react tag on the post, I assume you are trying to deploy react native app on Heroku, there is lots of information on internet how to do it.
For example this post.
Anyway first you need to build your app correctly, so static files would be generated (you didn't mentioned how you are running that app).
To your question:
Relative paths are the same on both local and server, but absolute paths will be different.
But for your 404 error I see that no static content are found on the root path.
So, I'm building an application with Vuejs and after we finish her we decided to finally build for production. Everything worked just fine while building and etc, but when the application was really being hosted, we noticed some issues that we do not saw while on localhost (development and production).
I'm saying this after a lot of tests and researches about it because first, I thought that the problem was after building to production but we tested another way to host and it's not apache that is causing this issue and I really think that is not the code either. Anyway the problem is when we first access the application our login page is the first that you can see and it works just fine at the first access but if the user refreshes the page for any reason the page loses all her CSS because the route /auth/login goes to /auth/login/ and after some tests I can confirm. That bar that is added at the end of the route makes the page lose CSS.
This problem we solved by adding an exception on our .htaccess (we know that this is not that best practice but anyway) after this solved we saw another problem: when we click on a link for example /auth/login?token=12334567890 the token param simply disappear and the user is automatically redirected to /auth/login. So we think that maybe these two problems are related because when we first access and log in everything inside the application works as it should, these two problems are only occurring on our login component. My question is what is causing this problem only on this page? It's a vue-router that is causing?
I am part of the developer team for a quite a large online system using ASP.NET(4).
Asp.net Ajax completely breaks down for Webkit browsers and we are getting full page postbacks when we should be getting partial only for the UpdatePanels.
I am starting to believe it has something to do with my Application Configuration, mainly for the following reasons.
If I move the ajax enabled controls to a new project they will work as expected for all browsers, including Webkit.
I created a static .aspx file with nothing but an UpdatePanel,ScriptManager and a button making a literal visible on click.
I get no Javascript errors from any browser, and i see an http request for the asp.net-ajax (ScriptResource.axd) in both Firebug and Chrome Developer tools
I tried ye'old safari fix from this highly referenced thread
Edit: After a bit more testing and http sniffing i noticed a major difference between the test application and the actual application. The test application generates 2 additional .axd files which are not generated from the actual application. These WebResource.axd, seem to contain data related to the async postback. However this is only the case for Webkit browsers. The WebResource.axd files are generated for Firefox as i can see them in firebug
What i am asking from the community, is any ideas or suggestions as to what could be the cause of this problem and if i am correct to assume that the problem is probably on the server side
Thanks for any help
The problem was due to a deprecated config file that's used to limit the content that bots/spiders/crawlers receive, which was loading by mistake thanks to our lovely inhouse CMS
In short if u get behavior similar to my case, check your or configs
I was having a similar issue however my problem was with all browsers and not just webkit. I ended up going through and tearing up the web.config file and found out that a line: <xhtmlConformance mode="Legacy"> was preventing webresource.axd from working properly. The fix was to simply remove that line from my web.config file.
For a little more information on xhtmlConformance, visit http://technet.microsoft.com/en-us/librarY/ms228268(v=vs.85).aspx.
If you scroll all the way to the bottom you'll notice it explicitly states that it causes issues with webresource.axd and scriptresource.axd.
I'm a web application developer, who runs a site http://myfav.es. We've been struggling with this issue for about a month now.
We use the HTML application cache spec - www.w3.org/TR/offline-webapps/ - with dynamically generated manifest files - myfav.es/personal.manifest - to speed page delivery. These dynamically generated manifest files use proper headers, and PHP to serve up custom manifests for users.
We also use gzip compression to serve the site from a linux/apache host.
For the life-cycle of our site, users report getting a err_failed similar to this screenshot in chrome. twitpic.com/272237.
This error is intermittent, occuring once every 200-300 visits, but will persists on every page refresh, including hard refreshes, which presumably means that an error using app cache is causing them to continuously load a failed version of the site. However, mysteriously JUST clearing cookies causes the error to fix itself.
I'm completely out of ideas on how to approach this error, and googling the error message appears to get a ton of confused users with voodoo-ish approaches to solving it. I've personally seen the error, along with a number of complaint from other users of chrome, so I'm fairly certain it cannot be caused by a particular user having abnormal settings or browser preferences.
Does anyone have any insight into the cause of this browser error and its origins? Whether its likely server-side or a byproduct of app design?