ETags plus gzip compression equals trouble
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Undecided
|
Leonard Richardson |
Bug Description
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.
Changed in launchpad: | |
status: | New → Triaged |
One thing we talked about was just turning off compression. I think this is most significant for the wadl file where Leonard reports we got 186k:15k compression ratio. Is that such a big deal?