I need to reload the page in Javascript. I use window.location.reload
for that purpose. Now, I observe a strange behaviour in Chrome: Chrome always connects to the server and asks if the document was modified. Though a 304 Not Modified
is returned, there is still a roundtrip to the server that I want to avoid.
I've also tried explicitly using window.location.reload(false)
to tell chrome to use the cache, but without success. Not that I have an active hash (#) fragment in the url that I reload.
The response headers of the resource are as following:
HTTP/1.1 304 Not Modified
Server: nginx/1.2.2
Date: Sat, 01 Jun 2013 13:19:56 GMT
Last-Modified: Sat, 01 Jun 2013 13:04:55 GMT
Connection: keep-alive
Expires: Sun, 02 Jun 2013 13:19:56 GMT
Cache-Control: max-age=86400
Access-Control-Allow-Origin: *
So, the Cache-Control
and the Expires
header are both set and should tell chrome not to update the resource within 24hours.
I do not reload the page using F5/CMD+R, but instead I click on a link, that will have a javascript event that will change window.location.hash
and then call window.location.reload(false)
. But Chrome keeps setting the Cache-Control: max-age=0
header for the request - which I don't want. Chrome should use it's internal cache and not send anything to the server at all.
There is no problem with the same code using Firefox, FF uses the cached version without connection to the server at all.
How can I fix this?
EDIT: Here is a simple example that you can use to tryout yourself: http://webspace.markdown.io/reloadtest.html
EDIT: I have developer tools closed and verify the headers via tcpdump -s 1024 -l -A dst port 80
on the server. I have also unticked "disable browser cache" in the developer tools.
EDIT 2: Note that if close the tab and enter the Url into a new one, Chrome correctly uses the cache. Only clicking a link (which will result in a window.location.reload
is affected.
Reloading the page, with either F5 or
window.location.reload
, makes a network connection even if navigating to the page from a different page would look directly in the cache. Whilereload(true)
forces it to bypass the cache (getting200
from the server instead of304
),reload(false)
does not force it to look at the cache before deciding if it needs to connect to the server.If the browser won't look in the cache to reload a page and it won't reload the page when a link is followed that only differs by the fragment, try fooling it into thinking it's loading a different page to get it to look in the cache. This uses ajax to get (from the cache) the page you're already looking at and with it replace the entire document. Then it replaces the URI fragment with a new one -- changing the fragment this way triggers whatever function in the JavaScript framework listens for changes in the fragment.
In the latest HTML5 draft (which is likely to become the final HTML5 standard without modification) the
location.reload()
function does not take any boolean parameter anymore. One should thus not rely on the parameter in any way when targeting HTML5.Answering myself, after some more research:
It simply can't be done.
The problem is not related to the
hash
value at all, and arises even if you don't use a hash.It seems
window.location.reload()
can not be used to control whether or not the current resource (indicated bywindow.location.href
) is to be used from cache or not. Although the documentation on MDN suggests otherwise. The official W3C specs on theLocation
object in thewindow
object are also not much of help.Chrome and Firefox will always perform a round-trip to the server, asking for the current resource, no matter what parameter you pass to
.reload()
. The parameter was originally introduced to forcePOST
requests be repeated asGET
requests - this has nothing to do with caching. (Carefull when using Firebug: I first thought FF does not send a request because it is not shown in Firebug - but when you look at the webserver logs, you can see that it actually does).I can observe that the presence of the boolean parameter influences whether or not the browser will append a
Cache-Control: max-age=0
header to the request. But this only reduces the data that is transfered, and will not eliminate the server connection at all. A roundtrip is done in any case.You could do something like that: