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 /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 > > >
