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

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.