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