intertwingly

Section 3.2 of Clarifying the Fundamentals of HTTP has a good explanation of this issue.

Etags can also be unique based on the server too, so if you’ve got multiple servers for a given site each could send a different etag for an identical file.  Yahoo!'s 13 simple rules for speeding up your web site recomends turning off etags all together.  Check out [link] (and the whole article).  Also, if you install the Firebug YSlow add on for Firefox you can check each of these rules against any page on your site.  It’s a pretty cool tool...

I disagree with your reading of the specification based on this sentence from RFC 2616:

The content-coding is a characteristic of the entity identified by the Request-URI.

Change the Content-Encoding and you change a characteristic of the entity, not a mere transmission artefact.

Is the reason mod_deflate doesn’t use Transfer-Encoding: gzip lack of browser support?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41

The Transfer-Encoding general-header field... differs from the content-coding in that the transfer-coding is a property of the message, not of the entity.

Seems a more accurate description of what’s actually done with an output filter, as opposed to say, what happens with AddEncoding gzip .gz .tgz or suchlike.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. ...the registry contains... “gzip”...

Is the reason mod_deflate doesn’t use Transfer-Encoding: gzip lack of browser support?

Another likely reason could be the fact that Transfer-Encoding is hop-by-hop.

Today I discovered a “problem” where Apache’s mod_deflate changes a resource’s ETag value from “foo” to "foo"-gzip when compressing the representation. This problem has been a while in coming , and after some research I’m convinced that Apache’s...