ETag should vary based on encoding

[GoogleCodeExporter]

Since we always have a modified time and unique URLs, we don't need to 
send/validate ETags, and dropping them will save bytes.

See: http://mrclay.org/index.php/2009/03/03/you-probably-dont-need-etag/

I think Minify::serve() could filter out the ETag, but HTTP_ConditionalGet 
should eventually be overhauled to consider more real-world ETag use cases.

Original issue reported on code.google.com by mrclay....@gmail.com on 3 Mar 2009 at 9:06

[GoogleCodeExporter]

@todo, fix typo in docblock for HTTP_ConditionalGet line 48 (should be 
'lastModifiedTime')

Original comment by mrclay....@gmail.com on 23 Mar 2009 at 5:57

[GoogleCodeExporter]

Whether or not Minify continues using them, it appears that HTTP_ConditionalGet 
should be extended to allow inserting knowledge of the client's Accept-Encoding 
and 
the Content-Encoding sent.

E.g. 
identity: ETag: "123456pub"
gzip    : ETag: "123456pub;g"
deflate : ETag: "123456pub;d"

When checking If-None-Match I believe it's sufficient to remove the /;\w$/ from 
the 
header and the ETag to be sent, but I'm still foggy as to how proxy caches deal 
with 
this and whether Vary should be included at all when ETags are available. 
Consulting 
the apache users list...

Original comment by mrclay....@gmail.com on 28 Mar 2009 at 10:14

[GoogleCodeExporter]

ETags now vary in R318. Still undecided whether to remove ETag support 
completely. 
In order to support ETags properly, we now have to sniff encoding on 
conditional 
requests, so there's a performance penalty.

Original comment by mrclay....@gmail.com on 30 Mar 2009 at 1:52

• Changed state: Started
• Added labels: Release-2.1.2

[GoogleCodeExporter]

Leaving ETags in for 2.1.3 release.

Original comment by mrclay....@gmail.com on 30 Jun 2009 at 4:59

• Changed state: NeedInfo

[GoogleCodeExporter]

Original comment by mrclay....@gmail.com on 1 Jul 2009 at 8:26

• Changed title: ETag should vary based on encoding
• Changed state: Verified