ETags plus gzip compression equals trouble

launchpadlib requests gzipped representations by putting "gzip" in Accept-Encoding. Apache automatically compresses the representations and puts "gzip" in Content-Encoding. So far, so good. BUT, Apache also messes with the ETag.

ETag: "foo"

becomes

ETag: "foo"-gzip

On the second request, launchpadlib sends a conditional GET request with '"foo"-gzip' as If-None-Match. Launchpad doesn't recognize the "gzip" that Apache slapped on there, and so the conditional GET fails. The whole representation is served again, needlessly.

Bizarre as it sounds, Apache is almost totally compliant with the HTTP standard here. (The one violation is that "-gzip" should be inside the quotes: the modified ETag should be '"foo-gzip"'.) What we want to do on the client side is put "gzip" in the TE header, not Accept-Encoding. And we want the server to put "gzip" in the Transfer-Encoding header, not Content-Encoding. Only then is it okay to leave the ETag alone. But Apache doesn't support this.

There are a number of options for resolving this but we're not sure which to use.