<html>
<head>
<meta http-equiv="cache-control" content="no-store">
</head>
<body>
lots of stuff
<meta http-equiv="cache-control" content="no-store">
</body>
<head>
<meta http-equiv="cache-control" content="no-store">
</head>
</html>
Moderator: General Moderators
I then reload the page with no change to the file (not to be confused with F5 refresh). "Status Code:304 Not Modified"Request Method:GET
Status Code:200 OK (from cache)
Remote Address:23.111.72.10:80
Response Headers
Accept-Ranges:bytes
Content-Length:51188
Content-Type:text/html
Date:Sat, 08 Oct 2016 15:19:26 GMT
Last-Modified:Sat, 08 Oct 2016 15:17:58 GMT
Server:Apache
Request Headers
Provisional headers are shown
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Now I change the file without closing down the browser. I just add a blank line somewhere then press the refresh button. "Status Code:200 OK"Request Method:GET
Status Code:304 Not Modified
Remote Address:23.111.72.10:80
Response Headers
view source
Connection:Keep-Alive
Date:Sat, 08 Oct 2016 15:22:41 GMT
Keep-Alive:timeout=5, max=100
Server:Apache
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:yourcommonsongjams.com
If-Modified-Since:Sat, 08 Oct 2016 15:17:58 GMT
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Request Method:GET
Status Code:200 OK
Remote Address:23.111.72.10:80
Response Headers
view source
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:51189
Content-Type:text/html
Date:Sat, 08 Oct 2016 15:24:38 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Sat, 08 Oct 2016 15:23:43 GMT
Server:Apache
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:yourcommonsongjams.com
If-Modified-Since:Sat, 08 Oct 2016 15:17:58 GMT
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Request Method:GET
Status Code:304 Not Modified
Remote Address:23.111.72.10:80
Response Headers
view source
Connection:Keep-Alive
Date:Sat, 08 Oct 2016 15:32:20 GMT
Keep-Alive:timeout=5, max=100
Server:Apache
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:yourcommonsongjams.com
If-Modified-Since:Sat, 08 Oct 2016 15:23:43 GMT
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
But my extra test in the summary with the bold underline shows that it did pick up the changed web page (It is only once in a while that it has the bug show up and it fails).A 200 "from cache" is not good because the browser is not contacting the server and thus cannot know if the file has changed;
It sounds like you are saying I need an expires header in my HTML. I am not sure what this means. I am doing google searches now to try and learn about this.However without there being an Expires header in the response or one in your HTML (double-check that) then I'm not quite sure what would cause it.
So you got: 200 from cache, 304, 200 no cache, 304.bowlesj wrote: Thanks requinix, I will send the three full examples then read the rest of your email and send another response...
That is what should be happening. You should never see a 200 from cache - always a regular 200 or a 304.bowlesj wrote: 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????
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.bowlesj wrote: 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.
Yes, either there's no cached version at all or the server responded with an updated copy.bowlesj wrote: 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.
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.bowlesj wrote: 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.
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.bowlesj wrote: 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.
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.bowlesj wrote: So I have been pressing F5 when this happens and it then gets my updated page. That is why I put in the javascript code to basically force an F5. I suspect chrome is not detecting a change in the file when I first open the browser but I am not sure.
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.bowlesj wrote: It sounds like you are saying I need an expires header in my HTML.
When you say "what I am seeing" I assume you mean my seeing "Status Code:200 OK (from cache)". So maybe here the browser is storing the page in cache first then displaying it and with ""Status Code:200 OK" it is displaying it first them storing it in cache???If it is caching the altered page then that could account for what you're seeing.
I have never seen the F12 developer tools network page when I got an old page from cache rather than my updated page from the server. I think what I will do this week is this. I will disable all the javascript code that forces a refresh. I will also remove all the meta stuff from all pages. I will set up a new test location on my website (you can see what I mean by going to my home page). I will make many changes during the day and see if I can reproduce this problem again. However when I check every single time I will press F12 first. If I get the old data I will immediately capture the info I pasted in the post above and add to this thread. Not only that, instead of pressing F5 I will next press the refresh button and see what message I get and post it here (also of course take note as to whether this brings up the proper latest data to the screen). Lastly maybe I will also press F5 and see what the message is.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?
I just checked the static pages that I copy up to the webhost. The javascript I showed in the first post was added after I detected the problem. Other than this the only javascript that changes the page is one that unhides and hides a table list of people attending the event. The others are functions that open another page. I needed to do that because I was having directory problems with storing the static pages in a different directory. I in theory could show you the actual static web pages except this website does not like the html extensionThe only thing I can think of is that you're using Javascript to alter the page in some way. Is that the case?
Code: Select all
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- saved from url=(0058)http://localhost/MJN/frmKaraoke_TableLayout.php?TimeSlot=3 -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Getting Started Picture</title>
<meta name="generator" content="WYSIWYG Web Builder 9 - http://www.wysiwygwebbuilder.com">So then I did a page refresh (not an F5). This time it got the proper update and gave this info.Request URL:http://yourcommonsongjams.com/
Request Method:GET
Status Code:200 OK (from cache)
Remote Address:23.111.72.10:80
Response Headers
Accept-Ranges:bytes
Content-Length:51586
Content-Type:text/html
Date:Sun, 09 Oct 2016 01:51:38 GMT
Last-Modified:Sun, 09 Oct 2016 01:50:17 GMT
Server:Apache
Request Headers
Provisional headers are shown
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Here is another incorrect one.Request URL:http://yourcommonsongjams.com/
Request Method:GET
Status Code:200 OK
Remote Address:23.111.72.10:80
Response Headers
view source
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:51587
Content-Type:text/html
Date:Sun, 09 Oct 2016 01:56:38 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Sun, 09 Oct 2016 01:51:21 GMT
Server:Apache
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:yourcommonsongjams.com
If-Modified-Since:Sun, 09 Oct 2016 01:50:17 GMT
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
And then a corrected one by pressing the refresh button.Request URL:http://yourcommonsongjams.com/index.html
Request Method:GET
Status Code:200 OK (from cache)
Remote Address:23.111.72.10:80
Response Headers
Accept-Ranges:bytes
Content-Length:51587
Content-Type:text/html
Date:Sun, 09 Oct 2016 02:16:34 GMT
Last-Modified:Sun, 09 Oct 2016 01:51:21 GMT
Server:Apache
Request Headers
Provisional headers are shown
Referer:http://yourcommonsongjams.com/frmKaraoke_TestPage.html
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
One more bad one. I am finished for the night.Request URL:http://yourcommonsongjams.com/index.html
Request Method:GET
Status Code:200 OK
Remote Address:23.111.72.10:80
Response Headers
view source
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:51586
Content-Type:text/html
Date:Sun, 09 Oct 2016 02:19:16 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Sun, 09 Oct 2016 02:17:52 GMT
Server:Apache
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:yourcommonsongjams.com
If-Modified-Since:Sun, 09 Oct 2016 01:51:21 GMT
Referer:http://yourcommonsongjams.com/frmKaraoke_TestPage.html
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Request URL:http://yourcommonsongjams.com/index.html
Request Method:GET
Status Code:200 OK (from cache)
Remote Address:23.111.72.10:80
Response Headers
Accept-Ranges:bytes
Content-Length:51586
Content-Type:text/html
Date:Sun, 09 Oct 2016 02:25:20 GMT
Last-Modified:Sun, 09 Oct 2016 02:17:52 GMT
Server:Apache
Request Headers
Provisional headers are shown
Referer:http://yourcommonsongjams.com/frmKaraoke_TestPage.html
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Yes.bowlesj wrote:Okay so let me repeat my understanding based upon what you wrote. The browser sends the page name and the last date it has for the page to the server. The server gets these two pieces of info and detects that the latest page it has on its disk has not changed since the date that the browser has sent and thus the server sends the 304 message to the browser (it does not bother sending the page). The browser uses this message to know it should use the cache version of the page to put on the screen for the user to see. On the other hand, if the server compared the browser date with the server's file date and saw a difference then it would not only send a regular "204 Ok" but it would also send the whole page for the browser to display.
Code: Select all
Header set Cache-Control no-cacheI assume you mean for the specific page involved. I am wondering what the difference between "no-cache" and the default is?no-store will not allow the browser to cache anything at all
I am wondering if anyone has actually proven this is a problem with heavy research. Logically chrome should simply dump anything it does not understand (essentially treating it as a comment). Therefore it should be taking the last one it understands. So as long as you do not duplicate what it understands in the wrong order you should be okay. Not only that how can one control multiple browsers without including multiple statements? By rights the statements should be grouped by browser helping to keep it all clear and with a comment before and after as I often do. For example: Start chrome commands then the commands then end chrome commands. After this Start firefox commands then the commands then end firefox commands. etc. Actually my very first post in this thread has two examples of what I mean regarding comments. Having said that if the same command has the opposite effect in two different browsers this creates a problem and there needs to be an if statement to first detect which browser is running (does the problem exist and can HTML have if statements?).But still remove the Javascript refresh and the additional <meta>s you had before. Keep the configuration as minimal as possible so there's no risk of one caching directive overriding or conflicting with another.
Right: there was nothing in the headers telling Chrome to cache results, which meant it was deciding to do so by itself.bowlesj wrote:Okay, thanks requinix. I will try those things. I take it you did not see anything special in the messages nor in my intial html code.
The default is... the browser does whatever it wants. Dynamic pages (eg, PHP) generally don't include any caching instructions so the browser picks some reasonable default behavior. Static pages generally don't include caching instructions either, but they do include things like Last-Modified dates or ETag identifiers and the browser can make decisions according to those.bowlesj wrote:I assume you mean for the specific page involved. I am wondering what the difference between "no-cache" and the default is?
Maybe. Or maybe it takes the first one and ignores the rest. Or maybe it tries to find a common denominator between the various settings.bowlesj wrote:I am wondering if anyone has actually proven this is a problem with heavy research. Logically chrome should simply dump anything it does not understand (essentially treating it as a comment). Therefore it should be taking the last one it understands.
I really don't know. My advice would be to pick one caching strategy (eg, using modification dates) and don't implement the others.bowlesj wrote:So as long as you do not duplicate what it understands in the wrong order you should be okay.
You don't. If you're explicit about caching then all the browsers will behave the same way. Because there's clear defined behavior they're supposed to follow. When you aren't explicit then they won't have any guidelines and will have to make educated guesses about what they should do.bowlesj wrote:Not only that how can one control multiple browsers without including multiple statements?
It seems that maybe the webhosting company does not have these configuration flags set up properly since neither chrome nor firefox pass the test?The only thing left to do is to ensure that the server is providing the necessary ETag tokens. Check your server documentation for the necessary configuration flags.
Code: Select all
<!-- START: HTML code to make sure your page is not stored in cache so that you do not need to tell them to use F5 -->
<!-- https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching NOTE: this is a good tutorial -->
<!-- http://www.i18nguy.com/markup/metatags.html NOTE: this has a good explaination of all the commands and why they are needed -->
<!-- http://www.htmlgoodies.com/beyond/reference/article.php/3472881/So-You-Dont-Want-To-Cache-Huh.htm NOTE: Microsoft IE only you may need to these commands again. -->
<!-- http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers NOTE: this gives a more complete set of commands to use -->
<meta http-equiv="cache-control" content="no-cache, public, max-age=86400">
<meta http-equiv="expires" content="0">
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT">
<meta http-equiv="pragma" content="no-cache">
<!-- END: HTML code to make sure your page is not stored in cache so that you do not need to tell them to use F5 -->