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?
问题:
回答1:
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.
回答2:
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.
回答3:
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.