> Bryan McQuade wrote... > > thanks! it is really great that you did this investigation.
You're welcome, but I wouldn't really call that an 'investigation'. More like just a quick 'observation'. > RE: checking to see if in cache, try typing the URL into the nav bar > and hitting "enter" rather than reloading. Tried that ( with Safari ). No conditional GET was sent. Behavior was the same as pressing the 'Refresh' Toolbar button. The entire document was 'Reloaded' and not 'Refreshed'. OT: If this discussion is going to continue let's agree that there IS, in fact, a difference between saying 'Reload' and 'Refresh'. On most browsers, the Toolbar button is SUPPOSED to behave as a 'Refresh' option. A browser is supposed to check its local cache and issue a 'conditional GET' request if it has a non-expired copy of the entity onboard. A RELOAD is when this local-cache-check process is 'skipped' and a browser simply disregards the content of its cache and RELOADS the page with no conditional GET request. CTRL-R is the industry standard browser RELOAD command. Works the same for both the MSIE and Mozilla/Firefox browser lineage. On Apple/Safari it's COMMAND-R. Interesting side note: Official documentation for Safari actually says the Toolbar Button is SUPPOSED to be the 'Refresh' option ( NOT RELOAD ), just like other browsers, and that pressing SHIFT-Refresh is the 'official' way to force a page to RELOAD instead of REFRESHING. If that is actually the case then the quick Safari test I did really would seem to indicate that the response with the 'Vary: Accept-Encoding' header was NOT CACHED. > most browsers use a more > aggressive reload algorithm (bypassing the cache for hte html) on > reload. Of course. See above about the established standards and the difference between 'Refresh' and 'Reload'. > also could you set an explicit resource expiration? otherwise you're > operating at the whim of caching heuristics which aren't explicitly > specified by the HTTP RFC. That is exactly why I did NOT add any resource control directives. The point of the test(s) was to observe the DEFAULT caching behavior. > Try setting an Expires or Cache-Control: > max-age header on your response. See > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4 for > info on heuristics. See above. I'm perfectly familiar with the directives. NOT using any of them is/was part of the testing. > In my tests most browsers implement the 10% rule but not all. YOUR tests? Exactly what tests are you referring to? Are you saying you already have some detailed caching tests for X number of browsers? Do you have any 'tests' of your own that involve 'Vary:' headers and local caching behavior? Can you share any of those results or would that violate Google's information sharing policy? > If you have time can you also test with safari4? Perhaps there was an > issue in 3.x that was fixed in 4.x. I am not an Apple person. I do not personally own any Apple hardware. The MacBook I used for a test is a loaner from a client. I will not/cannot change their current software configuration(s). Bryan, don't take this the wrong way, but everyone is perfectly aware of who you are and who you work for and what your/their agenda is. I'm not criticizing that in any way. You have every right to be here contributing to an open-source project... ...but remember that SOME of us just do this as a HOBBY. People like you are being PAID to be here and it's part of YOUR JOB to discover/know the answers to some of the questions. I. myself, am simply curious. There is no paycheck behind anything I do with regards to Apache. As an employee of Google I would imagine you have far more resources than I do up to and including any number of machines that you could configure with any browser you want for your OWN testing. > one thing that's also useful is to first load a page to put the > resource in the browser cache, then shut down the browser and restart > it to try to load that page again. this makes sure that the resource > was really persisted to the disk cache and isn't just being reserved > out of some temporary in memory cache. Great idea... you should make that part of YOUR testing. My curiosity has already been satisfied. Things are a little better than the were a few years ago. That was all I wanted to know yesterday. Now it's back to my REAL job, which has nothing to do with Content-encoding on the World Wide Web. > thanks again! very cool that you did this. >-bryan Again... you are welcome. Let me/us know how your OWN testing goes there at Google. Yours Kevin
