Re: current HTTP/2 spec prevents gzip of response to "Range" request

Up to now the accept-encoding is a negotiation and the implied one is 
not well worn. Potentially a HTTP/1.1 to HTTP2 gateway may be used to 
allow HTTP/1.1 clients to talk to HTTP2 servers. Existing HTTP/1.1 
clients may not support C-E gzip and the gateway can't do the 
decompression without affecting HTTP/1.1 functionality like range 
requests. So some HTTP/1.1 clients will be incompatible to the HTTP2 
world. This is okay if there is an agreement that this is acceptable.

Roland


On 25.03.2014 20:54, Patrick McManus wrote:
> I'm unlikely to implement a gzip transfer encoding decoder any time 
> soon. The distinction between TE and CE is too confusing and I think 
> we're better off without the footgun and just using a single defacto 
> CE mechanism instead (with all its admitted warts). The mandatory 
> implied Accept-Encoding codifies a well worn and useful optimization.. 
> Transfer-Encoding doesn't have the same track record to justify adding 
> it at the same level.
>
> I'm neutral on adjusting the spec to allow explicit gzip in TE and 
> Transfer-Encoding negotiated between consenting peers.
>
> -P
>
>
>
> On Tue, Mar 25, 2014 at 3:16 PM, <K.Morgan@iaea.org 
> <mailto:K.Morgan@iaea.org>> wrote:
>
>     Based on the feedback from the group thus far we have written up a
>     proposed replacement for section "9.3 GZip Content-Encoding". Our
>     proposal is based on using gzip transfer encoding. We are
>     proposing this route because, as Matthew pointed out, it allows
>     more freedom than a flag which is forever locked to gzip.
>
>     **NOTE: We believe our proposal still maintains backwards
>     compatibility with the poor misused/abused Content-Encoding
>     prevalent in HTTP/1.1**
>
>     > On 25 Mar 2014, Roy T. Fielding <fielding@gbiv.com
>     <mailto:fielding@gbiv.com>> wrote:
>
>     > just stop calling it content encoding. It is not the same thing.
>
>     We couldn't agree more!
>
>     Here is our proposal...
>
>     9.3 GZip Transfer-Encoding
>
>     Clients MUST support gzip compression for HTTP response bodies.
>     Regardless of the value of the TE request header field, a server
>     MAY send responses with gzip transfer encoding. A compressed
>     response MUST still bear an appropriate transfer-encoding header
>     field. This effectively changes the implicit value of the TE
>     header field ([HTTP-p2], Section 14.39) from "chunked" to "gzip,
>     chunked". Servers SHOULD not use gzip transfer encoding if the
>     requested content is already compressed (e.g. images, videos,
>     compressed files, etc.). Servers MUST not include the values
>     "gzip" or "deflate" in a Content-Encoding header, regardless of
>     whether the requested content is already compressed, but SHOULD
>     include the appropriate mime type in the Content-Type header.
>     Correspondingly, clients SHOULD not include the values "gzip" or
>     "deflate" in a Accept-Encoding header.
>
>     The following rules apply to intermediaries that perform
>     translation from HTTP/2 to HTTP/1.1:
>
>     1) if the request does not include an Accept-Encoding or TE header
>     that includes the value "gzip", the intermediary MUST decompress
>     the payload,
>
>     2) if the request includes an Accept-Encoding header that includes
>     the value "gzip", but does not include a TE header that includes
>     the value "gzip",
>
>     a) the intermediary MUST decompress payloads that are gzip
>     transfer encoded and have a :status header value of "206",
>
>     b) the intermediary SHOULD not decompress payloads that are gzip
>     transfer encoded and have a :status header value not "206", and if
>     the intermediary elects to keep the payload compressed, MUST
>     remove the value "gzip" from the Transfer-Encoding header and
>     insert the header "Content-Encoding: gzip" in order to maintain
>     backwards compatibility with HTTP/1.1 clients,
>
>     3) if the request includes a TE header that includes the value
>     "gzip", the intermediary SHOULD not decompress the payload.
>
>     Clients, servers and intermediaries MAY elect to support other
>     compression methods for transfer encoding, in which case it MUST
>     be explicitly requested by the client in the TE header.
>
>     Keith Morgan & Christoph Brunhuber
>
>     --
>
>     Keith S. Morgan
>
>     Remote Monitoring Unit
>
>     Safeguards, International Atomic Energy Agency (IAEA)
>
>     Vienna, Austria
>
>     Office: +43 1 2600 26672
>
>     Handy: +43 699 165 26672
>
>     This email message is intended only for the use of the named
>     recipient. Information contained in this email message and its
>     attachments may be privileged, confidential and protected from
>     disclosure. If you are not the intended recipient, please do not
>     read, copy, use or disclose this communication to others. Also
>     please notify the sender by replying to this message and then
>     delete it from your system.
>
>