You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by to...@aol.com on 2010/06/02 09:11:45 UTC
Re: Fast by default ( FWIW - Some tests )
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
Re: Fast by default ( FWIW - Some tests )
Posted by Sergey Chernyshev <se...@gmail.com>.
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, <to...@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
>
>
>