Re: Fast by default ( FWIW - Some tests )

[Sergey Chernyshev]

I think you're exactly right about Refresh button - it actually behaves
differently in different browsers.

In my opinion we should change the test with initiation by click instead as
majority of the use-cases are about caching assets between pages when user
goes from page to page.

I wonder if we can create a test using Browserscope:
http://www.browserscope.org/

http://www.browserscope.org/Just for reference - here's the post by Steve
Souders about writing such tests:
http://www.stevesouders.com/blog/2010/05/12/autohead-my-first-browserscope-user-test/
Here's the API: http://www.browserscope.org/user/tests/howto

I believe it's well suited for such tests, but didn't spend enough time with
them.

http://www.stevesouders.com/blog/2010/05/12/autohead-my-first-browserscope-user-test/
Sergey


On Wed, Jun 2, 2010 at 3:11 AM, toki...@aol.com wrote:


 Well, FWIW, I got curious about what the state of affairs is TODAY
 with this 'Vary: Accept-Encoding' deal and whether or not certain
 'modern' browsers will or won't actually CACHE the responses... so I took
 a few minutes and just did some simple tests with what I had available
 here in front of me today.

 These tests don't go anywhere near finding out what MIME types may or
 may not be fully supported for decoding by these 'modern' browsers.
 They ONLY test whether responses with 'Vary: Accept-Encoding' seem to
 be CACHED locally by the browser(s).

 The RESULTS, as they relate to this 'Fast by default' THREAD, don't
 really change any of the arguments much except that maybe things really
 HAVE gotten a little better in the last few years.

 IMHO, even these results ( interesting as they may be ) by no means
 'justify' turning 'deflate' ON as a default.


 ** SUMMARY

 When it comes to JUST the issue of whether a compressed response from
 Apache 2.x with a 'Vary: Accept-Encoding' header is or is not CACHED
 locally by the browser(s)... the news is GOOD for Firefox 3.0.18 and
 MSIE 7 ( Version: 7.0.6000.16982 )... but I'm not sure what to make
 of the 'results' for Apple's Safari Browser ( Version: 525.28.3 - MacBook
 ).

 It would APPEAR, at first glance, that Safari reverts to the old MSIE 5/6
 behavior and is REFUSING to cache any response with a 'Vary:
 Accept-Encoding'
 header... but monkeying around with the 'History' list produces confusing
 results. Maybe it did (cache), maybe it didn't. Hard to tell, really.


 ** DETAIL

 No kernel debugger was available on the machine in front of me so these
 were
 just presentation level 'see what happens' tests.

 The 'hello.htm' test file was just a 37,709 byte text/html file with no
 graphics.
 The actual content was just the first 9 or 10 pages of the RFC2616
 document.
 It was consistently compressed to 9,923 bytes on all '200' responses.


 *** FIREFOX ( Version: 3.0.18 )

 First request for 'hello.htm' using Firefox version 3.0.18...

 Apache 2.0.63 Server log reports...

 65.70.XX.XXX [02/Jun/2010:06:09:46 +0100] GET /hello.htm HTTP/1.1 200
 10410 - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.18)
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)

 Apache 2.0.63 Server responds with...

 200 OK
 Date: Wed, 02 Jun 2010 05:08:20 GMT
 Server: Apache/2.0.63 (FreeBSD)
 Last-Modified: Wed, 02 Jun 2010 04:58:56 GMT
 ETag: 152887c-907a-f2776400
 Accept-Ranges: bytes
 Vary: Accept-Encoding
 Content-Encoding: gzip
 Content-Length: 9923
 Connection: close
 Content-Type: text/html

 COMPRESSED CONTENT FOLLOWS

 ** Second request for the same 'hello.htm' document a moment later...
 ** Initiated by pressing the Firefox 3.0.18 Toolbar 'Refresh' button...

 Apache 2.0.63 Server log reports...

 65.70.XX.XXX [02/Jun/2010:06:12:08 +0100] GET /hello.htm HTTP/1.1 304
 335   - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.18)
 Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)

 It would appear that Firefox 3.0.18 did, in fact, cache the initial 200
 response
 that arrived with the 'Vary: Accept-Encoding' and 'did the right thing'
 when the
 Toolbar Refresh button was clicked.

 A conditional GET request was sent and '304 Not Modified' was returned.


 *** MSIE 7 ( Version: 7.0.6000.16982 )

 First request for the same 'hello.htm' page used for the Firefox test...

 Apache 2.0.63 Server log reports...

 65.70.XX.XXX [02/Jun/2010:06:26:17 +0100] GET /hello.htm HTTP/1.1 200
 10410 - Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
 CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)


 Apache 2.0.63 Server delivers the same response headers
 and compressed content as the Firefox test. The response
 headers contained 'Vary: Accept-Encoding' and 'Content-Encoding: gzip'.
 The only headers that were different were 'Date:' and 'Etag:'.

 ** Second request for the same 'hello.htm' document a moment later...
 ** Initiated by pressing the MSIE 7 Toolbar 'Refresh' button...

 Apache 2.0.63 Server log reports...

 65.70.XX.XXX [02/Jun/2010:06:27:26 +0100] GET 

Re: Fast by default (FWIW - Some tests)

[tokiley]

 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