httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Chernyshev <sergey.chernys...@gmail.com>
Subject Re: Fast by default ( FWIW - Some tests )
Date Wed, 02 Jun 2010 15:27:29 GMT
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, <tokiley@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 /hello.htm HTTP/1.1" 304
> 335   "-" "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)"
>
>
> Looks like MSIE 7 'did the right thing' and cached the initial 200 response
> that arrived with the 'Vary: Accept-Encoding' header. When Toolbar
> 'Refresh'
> button was hit a conditional GET went out and '304 Not Modified' came back.
>
>
> *** SAFARI ( Version: 525.28.3 - MacBook )
>
> First request for the same 'hello.htm' page used for other tests...
>
> Apache 2.0.63 Server log reports...
>
> 65.70.XX.XXX [02/Jun/2010:06:45:41 +0100] "GET /hello.htm HTTP/1.1" 200
> 10410 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
> AppleWebKit/525.28.3 (KHTML, like Gecko) Version/3.2.3 Safari/525.28.3"
>
> Apache 2.0.63 Server delivers the same response headers
> and compressed content as both the Firefox and MSIE test(s).
> The response headers contained 'Vary: Accept-Encoding' and
> 'Content-Encoding: gzip'. The only headers that were different
> were 'Date:' and 'Etag:'.
>
> 20 seconds later, A click on the Safari Toolbar 'Refresh' button shows...
>
> 65.70.XX.XXX [02/Jun/2010:06:46:05 +0100] "GET /hello.htm HTTP/1.1" 200
> 10410 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
> AppleWebKit/525.28.3 (KHTML, like Gecko) Version/3.2.3 Safari/525.28.3"
>
> FAILURE?
>
> The Safari browser did NOT send a 'conditional' GET request.
>
> It asked for the page all over again as if it was never cached and
> did, in fact, receive the entire page all over again.
>
> Same results on a 'back and forth' test. No conditional GET went out.
>
> The only way I could get the Safari browser to ever do a 'conditional GET'
> request on the page was by using the 'History' bar and selecting the
> document from the 'History' list.
>
> This is what the Apache log registers when you ask for the page THAT way
> instead of just pressing the 'Refresh' button...
>
> 65.70.XX.XXX [02/Jun/2010:06:56:50 +0100] "GET /hello.htm HTTP/1.1" 304 335
> "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
> AppleWebKit/525.28.3 (KHTML, like Gecko) Version/3.2.3 Safari/525.28.3"
>
> Only then did it appear as if Safari did, in fact, cache the original
> response
> that arrived with the 'Vary: Accept Encoding' header since it DID send a
> conditional GET and received the correct '304 Not Modified' response from
> the Apache Server.
>
> It is STILL UNKNOWN if this is any real proof that Safari is/was paying any
> attention to the 'Vary:' directive. It only means that the Toolbar
> 'Refresh'
> button seems to be hard-wired to NEVER do a 'Conditional' GET but the
> Safari 'History' option WILL.
>
> I find it a little hard to believe that the 'Refresh' button on a Safari
> browser will NOT issue a 'conditional GET' request even when it KNOWS it
> has a cached copy of a page. That just seems like a huge screw-up in the
> browser design if that is the case. Behavior like that sort of negates any
> need for the caching at all and means all the Apple folks are asking for
> 'new' copies of pages each and every time they just press the Toolbar
> 'Refresh' button. Yikes.
>
> I wonder if this is documented anywhere by people who analyze Network
> traffic...
> ...that the Apple/Safari folks are all hammering away at Servers because of
> the
> (apparent) behavior of that browser's 'Refresh' button?
>
> Yours
> Kevin Kiley
>
>
>

Mime
View raw message