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

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> 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> 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.
>