Re: GZip Content-Encoding / Reopen #404

+1

Even then it might be that there are some problems, e.g. my experience 
in the past with an iPhone playing a mp4 file was that it didn't 
accepted a full response on a range request and the video was not 
played. See for example 
http://stackoverflow.com/questions/10275730/php-video-play-on-ipad.

On 14.04.2014 04:23, Matthew Kerwin wrote:
> Section 9.3 in the current draft (-11 and the editor's copy) says that 
> clients MUST support gzip compression for HTTP response bodies. 
> "Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST 
> decompress payloads unless the request includes an Accept-Encoding 
> value that includes "gzip"."
>
> This goes some way to resolving issue #404 -- mnot's original report: 
> "the implication on a HTTP/1 to HTTP/2 intermediary should be spelled 
> out" -- but there are still a lot of implications not listed in that 
> requirement. According to my understanding of HTTP, the appropriate 
> added requirements are:
>
> For requests in the 1.1->2 direction without Accept-Encoding:gzip :
> * strip all conditional headers (If-Modified-Since, 
> If-Unmodified-Since, If-Match, If-None-Match, If-Range) [i]
> * strip all Range headers [i]
>
> For all responses in the 2->1.1 direction:
> * ought to strip Accept-Ranges headers
>
> For such a response with Content-Encoding:gzip that wasn't 
> Accept-Encoding:gzip :
> * gunzip the entity, appropriately update Content-Encoding, 
> Content-Length [ii], and add a Warning:214
> * maybe change :status: 200 to 203
> * strip or update Content-MD5 [iii]
> * strip Content-Location, ETag, Last-Modified headers from the 
> response [i]
> * if the request included Cache-Control:no-transform ???
>
> There may be others. If so, my implementation (if I were writing one) 
> would be lacking.
>
> There's still a big hole in "Cache-Control:no-transform". We've 
> essentially added a requirement that gateways break conformance, 
> without giving any guidance on how to do it (let alone reasonably 
> justifying it in the first place). We haven't even told them the 
> appropriate way to fail.
>
> In the absence of an opt-out mechanism for gzip C-E [iv], I think we 
> should remove the support requirement. In fact I think we should 
> remove section 9.3 altogether, but I'm not opposed to a strongly 
> worded suggestion that everyone support gzip.
>
>
> [i] or, in the case of a full-on transforming proxy, mint new 
> Last-Modified (possibly even ETag) header, and be responsible for 
> mapping the uncompressed entity on the 1.1 side to the compressed 
> entity on the 2 side
>
> [ii] since HTTP 2 is already fragmented by frames, a gateway is 
> probably going to always respond with chunked T-E, so Content-Length 
> should probably be stripped (if present) anyway.
>
> [iii] thus explicitly acting as a non-transparent proxy according to 
> RFC 2616, Section 13.5.2 (Non-modifiable Headers). I can't find the 
> equivalent text in the HTTPbis drafts, but I assume there's something 
> in there.
>
> [iv] an alternative could be to use Cache-Control:no-transform as such 
> a flag; i.e. a server MUST NOT apply gzip C-E if the request did not 
> include Accept-Encoding:gzip and did include 
> Cache-Control:no-transform. That seems a bit flaky to me, though, and 
> easy to miss/get wrong.
>
> -- 
>   Matthew Kerwin
> http://matthew.kerwin.net.au/