On my website, www.johnshammas.com, it works perfectly in all browsers. Except...anyone that has viewed the previous version on Chrome is stuck with that version until they empty their cache. What would cause the website to return a "not modified" header when in reality it has been modified heavily?
If a 304 Not Modified response was returned, it was because earlier the server sent a response with an ETag or a Last-Modified header.
Later, the browser sent this value as an ETag or If-Modified-Since header. The server recognized the ETag or date such that the resource had not changed since the browser last requested it.
So it returned a 304.
If you are not familiar with these or other cache headers, I recommend doing some research on them. There are many great tutorials on what these are and how to use them.
A few possible solutions go like this...
No 1 (Permanent)
F12 for Dev Tools > Gear symbol for settings in the lower right > Network > Check "Disable cache"
No 2 (Semi-Permanent)
Switch to Incognito mode via Ctrl + Shift + N. But watch out as this
also ends your session.
No 3 (One-Time)
Ctrl + Shift + Del > Confirm
No 4 (One-Time)
F12 for Dev Tools > Network Tab > Right Click content area >
Clear browser cache > Confirm.
The problem is that Chrome needs to have must-revalidate in the Cache-Control` header in order to re-check files to see if they need to be re-fetched.
Recommend the following response header:
Cache-Control: must-validate
This tells Chrome to check with the server, and see if there is a newer file. IF there is a newer file, it will receive it in the response. If not, it will receive a 304 response, and the assurance that the one in the cache is up to date.
If you do NOT set this header, then in the absence of any other setting that invalidates the file, Chrome will never check with the server to see if there is a newer version.
Here is a blog post that discusses the issue further.
Related
We saw this issue on one of our dev machines - the vendor.js bundle in our Angular project had somehow gotten cached, while truncated, which breaks the web app until you clear the cache.
We do use browser caching (together with URL-hashing so caching doesn't prevent app updates).
Is there any way to prevent the browser from caching a truncated request? Actually, I would have thought that the browser has this built-in (i.e. it won't cache a request where the bytes header does not match the amount downloaded).
The browser where we reproduced the problem was Chrome.
I think I found the issue - for whatever reason, our HTTP Response was missing the "Content-Length" header in the Response Headers.
The response passes through 2 proxies so one of them might remove the "Content-Length" header.
What we did in such a case is to add a parameter for the request of a lib.
You just need to raise the number and next time the browser and the caches in between will fetch a new version from the server:
e.g. www.myserver.com/libs/vendor.js?t=12254565
www.myserver.com/libs/vendor.js?t=12254566
I am trying to play an mp4 video on my website using window.location = path-to-file/file-name.mp4 through Chrome. Although the video plays, Chrome Developer Tools Network tab shows that that the request continuously gets cancelled and resent:
.
I have left the Developer Tools window open and it has shown that more than 5000 requests have been made and over 600 MB transferred :
It's beyond me why this is happening. I have tried looking at the the request and response headers for the first 4 requests to see if I could spot something obvious (I am by no means an expert):
and the only thing I can see is that the RANGE and CONTENT-RANGE in the request and response headers, respectively, seems to be changing. I also noticed that the very first response has TRANSFER-ENCODING set to CHUNKED.
I tried researching these terms but was not able to come to any conclusions (except the one that I still have a lot to learn, haha). If anyone could please provide any help or point me in the right direction I would be most appreciative :)
Thanks for your help!
EDIT : I would like to add that I am not explicitly creating a GET request with XMLHttpRequest, just using window.location to play the video in a new window.
I found that specific client(win7 + IE8) can't download a file(PDF file)
which contains Cache-Control:no-cache in HTTP header;
http://www.doosan.com/doosaniv/download.do?path=product&sav=225806754671.pdf&ori=d70s-5_plus.pdf&dir=20110630
But if the header contains Cache-Control:no-cache="set-cookie, there's no problem to download.
http://www.doosan.com/doosaniv/download.do?path=product&sav=225515770296.pdf&ori=d18s-5.pdf&dir=20110630
And.. in the first situation, If I run IE8 as Administrator, got no problem to download..
(Note that I logon as Administrator in win7. It's weird..)
I fount a blog and it says SSL and no-cache. I think it's similar but different problem.
Thank you.
Thank you for posting this question. The links and examples were very helpful in solving other problems.
From the MSDN article you link to:
"if a user tries to download* a file over a HTTPS connection, any response headers that prevent caching will cause the file download process to fail."
I'm guessing that IE8 doesn't respect Cache-Control:no-cache="set-cookie" as a proper header, and thus believes there is nothing preventing cache and the download is allowed to continue.
It's the first time I am doing something with headers. I am mainly concerned with Cache-Control but there may be others I will need to check as well. For example, I try to send the following header to the browser (based on tutorials I just read):
Cache-Control:private, max-age=2011-12-30 11:40:56
Google Chrome displays it this way in Network -> Headers -> Response headers, but how do I know if it's correct, that there aren't any typos, syntax errors and such? Will it really work? Will the browser behave like I want it to, or will it treat it like a gibberish (something like "unknown header/value")? I've tried sending nonsensical headers on purpose but they got displayed with the rest. Is there any Chrome tool / addon for that, or any other way? Thank you in advance!
I'm afraid you won't be able to check if the resource has been cached by proxies en route, but you can check if your browser has cached it.
While in the Network panel of Chrome DevTools, hit F5 to reload your page. You should see something like "304 Not Modified" in the status field for the resource you are treating (which means the resource has not been modified and its contents were not received from the server but rather loaded from the browser's cache.)
When Chrome loads my website, it checks the server for updated versions of files before it shows them. (Images/Javascript/CSS) It gets a 304 from the server because I never edit external javascript, css or images.
What I want it to do, is display the images without even checking the server.
Here are the headers:
Connection:keep-alive
Date:Tue, 03 Aug 2010 21:39:32 GMT
ETag:"2792c73-b1-48cd0909d96ed"
Expires:Thu, 02 Sep 2010 21:39:32 GMT
Server:Apache/Nginx/Varnish
How do I make it not check the server?
Make sure you have the disable cache checkbox unchecked/disabled in the Developer Tools.
What do your request headers look like?
Chrome will set max-age:0 on the request's Cache-Control header if you press Enter in the location bar. If you visit your page using a hyperlink, it should use the cache, as expected.
Wow! I was facing the same issue for quite some time.
I'll tell you why you were facing this issue. Your headers are just fine. You receive a 304 because of the way you are trying to refresh the page. There a mainly 3 ways -
Press enter in the address box. You will observe chrome reads the file from the cache first and does not go to the server at all.
Press f5, this would verify if the file has become stale (probably that is how you are refreshing)
Press Ctrl+f5, this is unconditional reload of all static resources.
So basically - you should press the return key in the address bar. Let me know if this works.
For me, it was self-signed certificate:
https://code.google.com/p/chromium/issues/detail?id=110649
In the above link the Chromium Developer marked the bug: #WontFix because the rule is: "Any error with the certificate means the page will not be cached."
Therefore Chrome doesn't cache resources from servers with self-signed certificate.
If you want Chrome to cache your JS/CSS files - the server will need to set a "Cache-Control" header. It should look like:
Cache-Control:max-age=86400 (if you want to cache resources for a day).
I believe you are looking for
Cache-Control: immutable