Thanks requinix, I will send the three full examples then read the rest of your email and send another response...
So you got: 200 from cache, 304, 200 no cache, 304.
The first 200 is likely ("should be") due to the old file having various caching settings and such. You would need to refresh until you stopped getting that - it means the browser forgot what it had before and reached out to the server again. The next 304 is because the browser reached out, saw no changes, and reused the cached version. That's good.
After you made the change, the next 200 is the correct behavior: browser reached out again, saw changes, and used the new version. The subsequent 304 is the same as before, where the browser was told there were no changes and served the cached copy.
Without adding any caching things, you should always get an uncached 200 or a 304 for every request afterwards - regardless of whether you restart the browser. If that is not the case (ie, you get a 200 from cache) then there is something still applying caching settings... and in those example request/responses you posted, I'm not seeing it.
1/ Status Code:200 OK (from cache) - It gives me this when I close and open the browser again. I double checked this and it just got the actual webpage changes????
That is what should be happening. You should never see a 200 from cache - always a regular 200 or a 304.
2/ Status Code:304 Not Modified - It gives me this if it detects that the file date has not been modified. I assume it is using cache and not getting the page.
Meaning: The browser cached the page from the last time you visited, and noted the Last-Modified date that the server reported. The next time it requested the page it included the modification date and gave the server the option of indicating that the page hasn't changed without returning the page's contents again
. 304 means there was no change and the browser should redisplay the cached version from before.
3/ Status Code:200 OK - It gives me this if it detects that the file date has been modified. Obviously it is going to get the page here.
Yes, either there's no cached version at all or the server responded with an updated copy.
4/ Status Code:304 Not Modified - If I press F5 it must be forced to read the file again (not use cache) but it still gives this message if the file has not been modified.
I'm not sure that hitting F5 always forces an uncached page, but it does tend to disregard the cache more often when you do.
The problem is real as pressing F5 proves:
Every so often chrome thinks there is no change to the file and does not display the latest updates.
This is the problem we're trying to solve: why Chrome reuses a cached copy when it should not. I promise you that there is not a bug in Chrome regarding caching - rather there is something else going on we haven't identified yet.
page. If it is caching the altered page then that could account for what you're seeing.Question:
Doing the F5/update the file/F5 stuff from before, what is the request and response for when you see that the page does not appear to have updated?
Quick correction: Chrome is not detecting any changes at all. It is only reported by the server: it sends the Last-Modified date that it has, then Chrome stores and uses that. The server is what decides whether to return a 200 or a 304. When I've said that it didn't "see" changes, I'm simplifying: it didn't see that the server said that
there were changes.
It sounds like you are saying I need an expires header in my HTML.
Expires is bad. Don't use it. As far as I've been able to determine with what you've said, Last-Modified is perfectly adequate for your usage.