I'm having problems with a website is Chrome.
Most of the site uses ajax/xmlhttprequest for pages loads and the history API to enable the back button. Only the page content is changing with the request, the menu etc are never reloaded. This just re-reuns the ajax request for the previous page. This all works fine until someone clicks the back button after viewing the blog. The blog isn't loaded with ajax, it's just a standard link.
In Firefox if I go to the blog then press back the site loads correctly. The main page with the navigation loaded and so is the page to be viewed within it.
In Chrome however if I press the back button from the blog the 'outer' page isn't loaded, only the contents of the ajax request is. You may need to view it to fully understand.
Is this a bug in Chrome or my work? It seems I can't return to a page that was partially loaded using xmlhttprequest as only the requested item is loaded.
The site is here: http://www.basmooarc.com
Thanks
Ric
short answer
Add a Cache-Control: no-store HTTP header for XHR responses.
long answer
I'm pretty sure this is a bug in Chrome. I found the exact same bug in my app, and it works fine in Firefox but breaks in Chrome. I think the issue is that Chrome caches the XHR response and serves it from the cache when you press the back button. My app uses Etags, but Chrome does not bother to check the Etag. It just uses the cached response, which is missing all the outer content. The best solution I've come up with so far is to add no-store to the cache control header for XHR responses.
You can see the behavior through Chrome's net-internals page. Type chrome://net-internals in the URL bar, open the Events tab and go through the steps to reproduce your bug. When you go to a non-ajax page and then press the back button, you'll see a URL_REQUEST entry for the URL of the page you're trying to go to, but Chrome just checks the cache and that's it. Contrast that with a normal request for that URL. The normal one will have a cache check, followed by an HTTP_TRANSACTION_SEND_REQUEST section, which is where Chrome makes the actual HTTP request.
Related
I have a Greasemonkey script that fixes a rather broken redirect on a web application that I use. However, the behavior of this application has recently changed so that I can no longer use beforescriptexecute for one common case, causing the poorly designed redirect to happen.
This happens with a HTTP 301 status code and a Location header.
I've been digging through https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers but have not been able to work out one that can intercept the page before the browser redirects me. Is there any event that fires before the 301 redirect occurs that I can hook onto with Greasemonkey?
I have a webapp that uses AJAX calls to load HTML snippets in various places. Note that the webapp also simulates regular navigation with the use of history.pushState function (not sure it has anything to do with my problem but I still mention it).
Problem:
Whenever I exit the browser with a tab displaying my webapp and restart it again, the browser does not trigger a regular HTTP request to load the whole page. It simply uses a cache mechanism to load the response of the latest HTTP request. In my case, if the last request happens to be an AJAX call, then the browser will only load the HTML snippet without css, js nor the rest of the HTML.
Note that the problem appears in Firefox. In IE, the whole page can be reloaded if you accept the execution of scripts when being prompted. Chrome works fine as it loads the entire page.
Question:
Is this a normal behavior and how can I prevent it (i.e. make it work like in Chrome)?
Thanks for helping!
This is not a Meta question.
I am trying to technically understand what principle is hidden behind the following behaviour. It's very easy to reproduce:
Vote up/down anything on this page1,
Click on any other link on this page,
Come back by pressing the back button.
Your upvote is not there anymore as well as any AJAX activities having appeared on the page.
Why is that? Why is the browser acting like so? How could StackOverflow prevent that?
1 If you are not connected, just wait for someone else's activity on the page (new comment, answer, vote) before moving page.
It’s the browser’s cache that is at play here.
Since you’re asked how SO could “prevent” this, it could be done by advising the browser to check for whether the document has changed every time. But SO not doing so, for performance reasons. So the HTML document is seen as “still valid” for a certain amount of time, during which the browser takes it straight from its cache, without making a round-trip to the server.
If you look at the HTTP response headers in your browser’s developer tools for the request your browser made for this page, you will see something like this,
Cache-Control: public, no-cache="Set-Cookie", max-age=60
– so this HTML document is to be considered valid for 60 seconds. If you navigate away from it and back in your browser, or close the tab and reopen it from history, within that 60 seconds, the browser is supposed to take the cached version of it and display it, without checking again with the server whether or not something has changed. And since your vote did not manipulate this original HTML document (only the DOM was updated with your vote), you still get the previous vote count shown.
But if you press [F5] in your browser, the cache will be circumvented – it will request the document from SO again, and then you see your vote, because this time the updated numbers are part of the updated HTML document that SO serves you.
If you want to delve more into HTTP caching, some resources of the top of Google that seem worth a look:
Caching Tutorial for Web Authors and Webmasters
A Beginner's Guide to HTTP Cache Headers
You are not "unvoting", you just are not seeing your vote because your browser is caching the ajax request.
If your press F12 on Chrome, click on Settings icon and then "Disable cache (while DevTools is open)", when you press back the browser will resend the request.
To prevent that you must specify on your code that you never want that specific request to be cached.
You may want to check the following post:
Prevent browser caching of jQuery AJAX call result
-
Ps. You must stay with the Console (F12) opened while doing the test.
We're developing a web application that handles state change via change of the hash of the page (e.g. example.com/#/page1).
Lately, I've been running into an issue with Google Chrome, when the prefetch option is enabled ("Predict network actions to improve page load performance"). Among the different routes, we have #/logout that performs the logout.
In the "normal" state, I'm on the page example.com/#/ (the main page), and as I start typing "l" after that (example.com/#/l), Chrome autocompletes with logout. However, not only it does autocomplete, but it also calls the "haschange" event, so the client is sending a request to log out to the server... Even just by typing a l!
This behaviour is not only unexpected, but it's also dangerous. Aside from unchecking "Predict network actions to improve page load performance" in the settings page (which is on by default), is there a way to prevent Chrome to do this?
EDIT
A small new "discovery". Actually, Chrome is not firing the "hashchange" event, as a console.log in the event handler is not being executed. Chrome learnt that, when visiting the #/logout page, a request to the server (GET /auth/destroy) is called, and so it's firing it by itself! What can we do to stop this?
Answering my own question. This is not really a solution, but rather a workaround.
According to this documentation, prendering is disabled in certain situations: with POST requests (not an option in our case) and when the resources are served via HTTPS.
Since we were already going to enable HTTPS in the production environment, we just enabled it in the development one as well and the issue disappeared. However, I still feel like this is more of a workaround than a real solution.
I've been using HInclude (http://www.mnot.net/javascript/hinclude/) for sometime now and its working great, but there is one problem though. The part of my site which is fetched using HInclude doesn't get refreshed everytime I hit the back button in Internet Exploer (6.x + and 7.0 also). It works fine on other browsers. I've tried setting the cache-control and pragma controls in header to "no-Cache". but even that is not working. I want HInclude to pick up new content everytime a user clicks back button or re-visits a page with hx content on it. How do I do that?
did you try to put some random string in the end of your JS link ?
A full traffic capture would be useful to see exactly what your server is sending. Having said that, the IE team did work in IE9 to help ensure that hitting the Back button wouldn't hit the server, as allowed by RFC2616 and as implemented in other browsers.
Prior to IE9, the back behavior was pretty screwy/buggy and whether the server got hit could depend on whether the page had explicit caching directives and what the user's IE cache settings were (see midway through this document). In practice, the server was hit much more often than it should have been (which is, of course, never).
If I recall correctly, I think one of the pre-IE9 bugs was to that if the caching headers contained must-revalidate, the client wouldn't pull the file from cache.
-Eric