I might be wrong, but doesn't HTTP require the Expires header to be set a date less than or equal to one year in the future? If so, the test might have hit undefined behavior.
"To mark a response as 'never expires,' an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future." -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
In practice, far-future expiration headers used by Yahoo!, Google, and others are often well over a year in the future, and all browsers support this just fine.
I did do some sanity checks using various dates in the headers, and I saw no difference between dates of less than a year and dates over a year in the future. I decided to run the canonical tests using the far-future dates since that's what the majority of websites use these days.
Would love to see the tests re-run on real data that can be gzipped. You mention that your Sinatra-based tool: "generates a response consisting of a requested number of pseudorandom alphanumeric and whitespace bytes." Then you say that "gzip had no effect on cacheability on any device." I believe that your conclusion that gzip doesn't work is because it's hard to compress random (or pseudorandom) text.
Actually, the reason is that the browser uncompresses components before caching them, so compression has no effect on cacheability.
The generated data are actually a series of newline-delimited MD5 hashes of pseudorandom numbers, which makes them fairly compressible. For example, 32KB of data gzips down to about 18.9KB, which seems to me like a pretty reasonable representation of typical web content.
I didn't conclude that gzip "doesn't work", just that it has no effect on cacheability. Gzip is certainly good for reducing the number of bytes on the wire, though.
Why do browsers have such ridiculously low default cache limits? Desktop browsers do the same thing; Firefox's default cache size is 50 MB. That's 0.01% of my available storage. I'd be more than happy to devote a whole 1% of my storage to speeding up web browsing, which is after all the primary activity most people perform on a computer these days. That would give a cache size of ~150 MB on an iPhone and 5 GB on my desktop.
8 comments
[ 2.8 ms ] story [ 29.8 ms ] thread"To mark a response as 'never expires,' an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future." -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
In practice, far-future expiration headers used by Yahoo!, Google, and others are often well over a year in the future, and all browsers support this just fine.
I did do some sanity checks using various dates in the headers, and I saw no difference between dates of less than a year and dates over a year in the future. I decided to run the canonical tests using the far-future dates since that's what the majority of websites use these days.
The generated data are actually a series of newline-delimited MD5 hashes of pseudorandom numbers, which makes them fairly compressible. For example, 32KB of data gzips down to about 18.9KB, which seems to me like a pretty reasonable representation of typical web content.
I didn't conclude that gzip "doesn't work", just that it has no effect on cacheability. Gzip is certainly good for reducing the number of bytes on the wire, though.