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

Recording this as:
  https://github.com/http2/http2-spec/issues/445


On 26 Mar 2014, at 6:54 am, Patrick McManus <pmcmanus@mozilla.com> 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> 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.
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 31 March 2014 06:15:31 UTC