httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From toki...@aol.com
Subject Re: Fast by default ( FWIW - Some tests )
Date Wed, 02 Jun 2010 07:11:45 GMT

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