GZip Content-Encoding / Reopen #404

Section 9.3 in the current draft (-11 and the editor's copy) says that
clients MUST support gzip compression for HTTP response bodies.
"Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST
decompress payloads unless the request includes an Accept-Encoding value
that includes "gzip"."

This goes some way to resolving issue #404 -- mnot's original report: "the
implication on a HTTP/1 to HTTP/2 intermediary should be spelled out" --
but there are still a lot of implications not listed in that requirement.
According to my understanding of HTTP, the appropriate added requirements
are:

For requests in the 1.1->2 direction without Accept-Encoding:gzip :
* strip all conditional headers (If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, If-Range) [i]
* strip all Range headers [i]

For all responses in the 2->1.1 direction:
* ought to strip Accept-Ranges headers

For such a response with Content-Encoding:gzip that wasn't
Accept-Encoding:gzip :
* gunzip the entity, appropriately update Content-Encoding, Content-Length
[ii], and add a Warning:214
* maybe change :status: 200 to 203
* strip or update Content-MD5 [iii]
* strip Content-Location, ETag, Last-Modified headers from the response [i]
* if the request included Cache-Control:no-transform ???

There may be others. If so, my implementation (if I were writing one) would
be lacking.

There's still a big hole in "Cache-Control:no-transform". We've essentially
added a requirement that gateways break conformance, without giving any
guidance on how to do it (let alone reasonably justifying it in the first
place). We haven't even told them the appropriate way to fail.

In the absence of an opt-out mechanism for gzip C-E [iv], I think we should
remove the support requirement. In fact I think we should remove section
9.3 altogether, but I'm not opposed to a strongly worded suggestion that
everyone support gzip.


[i] or, in the case of a full-on transforming proxy, mint new Last-Modified
(possibly even ETag) header, and be responsible for mapping the
uncompressed entity on the 1.1 side to the compressed entity on the 2 side

[ii] since HTTP 2 is already fragmented by frames, a gateway is probably
going to always respond with chunked T-E, so Content-Length should probably
be stripped (if present) anyway.

[iii] thus explicitly acting as a non-transparent proxy according to RFC
2616, Section 13.5.2 (Non-modifiable Headers). I can't find the equivalent
text in the HTTPbis drafts, but I assume there's something in there.

[iv] an alternative could be to use Cache-Control:no-transform as such a
flag; i.e. a server MUST NOT apply gzip C-E if the request did not include
Accept-Encoding:gzip and did include Cache-Control:no-transform. That seems
a bit flaky to me, though, and easy to miss/get wrong.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/