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

With content-encoding the gzip compressed content and the uncompressed 
content are two entities. By requiring the client supporting gzip 
content-encoding the server is freed from the burden to know about the 
uncompressed content. When the client works on the uncompressed content 
then this makes it difficult for the client to compute the correct 
range. For example video players doing a seek may have an issue. In 
HTTP/1.1 the client can send the range request to the uncompressed 
content if it is willing to accept uncompressed content (or it is 
already compressed like a video), but in HTTP/2 this would no longer be 
possible.

The advantage of the transfer encoding would be that the requested range 
is for the uncompressed content and the server would be able to just 
compress the requested part of the content on the fly. Also 
intermediaries can decompress the content if they wish in order to 
examine the content. Quite often content-encoding is just used to 
compress the content for the transfer without thinking about the 
potential problems like caches storing two versions.

Regards,
Roland


On 24.03.2014 17:40, Martin Thomson wrote:
> I think perhaps that you have Transfer-Encoding confused with Content-Encoding.
>
> HTTP/2 does not change the characteristics of the protocol with
> respect to ranges.  We do change Content-Encoding to requirement that
> the client support gzip, but this doesn't affect the case you
> describe.
>

Received on Monday, 24 March 2014 17:47:18 UTC