Re: Fast by default (FWIW - Some tests)

[to...@aol.com]

> 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