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
