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

I like the idea of requiring transfer encoding instead of content 
encoding but I have concerns regarding replacing content-encoding by 
transfer encoding. When a 200 response is forwarded to a 1.1 client by 
an intermediary as content-encoding then the gzipped content is the 
same. However in HTTP/1.1 with content-encoding the gzipped content is a 
different entity than the not gzipped. If the client make further 
requests based on the content received then it will use the ETag from 
the server (for the uncompressed content) or one invented by the 
intermediary (for the compressed content). In both cases something may 
go wrong on further requests, for example a cache validation may fail. 
For a followup range request this would mean that the client does it on 
the compressed content and the server will assume the range is for the 
uncompressed content and the wrong range will be returned.

This gets especially complicated if it is assumed that the client is 
roaming between networks and cache partial responses.

Maybe something like this may work:

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". Clients 
SHOULD not include the values "gzip" or "deflate" in a Accept-Encoding 
header. Intermediaries translating from HTTP/1.1 to HTTP/2 SHOULD 
forward the Accept-Encoding header. If there is an Accept-Encoding 
header containing gzip as value then servers MAY use gzip 
Content-Encoding instead of gzip Transfer-Encoding.



Mandating content-encoding gzip has the same issue as it is not mandated 
in HTTP/1.1 and a gateway can't really translate.

Regards,
Roland


On 25.03.2014 20:16, 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,
>
The vary header should be set to include accept-encoding. What to do 
with a potential ETag?
>
> 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.
>