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

On Mar 24, 2014, at 10:04 AM, Martin Thomson wrote:

> On 24 March 2014 09:53, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>> Section 8.1.3. of the current draft is quite clear that implementations
>> must not indicate acceptance of or support for transfer encodings using
>> the `TE` header; it seems clear that `Transfer-Encoding: gzip, chunked`
>> is not supposed to be used in HTTP/2.0, which is exactly the issue here.
> 
> That's because Transfer-Encoding is a hop-by-hop thing and the
> non-standard "gzip" Transfer-Encoding would need to be understood by
> all hops in the chain if it were to be used for ranges.  I'm not aware
> of any use of Transfer-Encoding other than "chunked", because it's
> virtually impossible to define a new one that interoperates.
> 
> As I said, I think that this is a confusion between two different but
> oft-confused headers:
> 
> Content-Encoding: gzip
> Transfer-Encoding: chunked

It seems you have confused them.  Transfer Encoding is something
that can be added or removed by the protocol.  Content Encoding is
metadata about the representation.  If the protocol modifies a value
for CE, then it breaks anything that relies on the payload being
delivered without transformation (e.g., ranges and signature metadata).

If HTTP/2 doesn't allow compression transfer encodings, then it doesn't
allow compression by intermediaries. I assumed that TE was replaced by
a framing mechanism that indicates the payload has been compressed.
If that isn't so, then HTTP/2 will be less efficient than HTTP/1 for
some use cases (like CDNs).

And, no, it isn't virtually impossible to introduce standard transfer
codings.  It just requires effort by browsers to support one.
It also isn't necessary to restrict HTTP/2 features to what a current
browser supports.

....Roy

Received on Monday, 24 March 2014 20:19:39 UTC