- From: Roland Zink <roland@zinks.de>
- Date: Fri, 11 Apr 2014 20:59:42 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
If this was always in then I problably misunderstood issue #424 (https://github.com/http2/http2-spec/issues/424) and the consensus call to it http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1118.html. The problem itself still persists and I mentioned this repeatedly, but see also Keith's mail (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0175.html), Julian's message (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0179.html) and issue 445 https://github.com/http2/http2-spec/issues/445. The requirement to support gzip compression doesn't hold for HTTP/1.1 clients and a HTTP/1.1 to HTTP2 gateway would either need to decompress violating the end to end property of content encoding or some HTTP/1.1 clients are incompatible. Using T-E instead of C-E would be a possible solution to the problem. Regards, Roland On 11.04.2014 20:22, Martin Thomson wrote: > On 11 April 2014 10:53, Roland Zink <roland@zinks.de> wrote: >> Hi Martin, >> >> So the following text was modified? >> >> Roland >> >> 9.3 GZip Content-Encoding >> >> Clients MUST support gzip compression for HTTP response bodies. Regardless >> of the value of the accept-encoding header field, a server MAY send >> responses with gzip encoding. > draft-mbelshe-httpbis-spdy-00 included the following text: > > User-agents MUST support gzip compression. Regardless of the > Accept-Encoding sent by the user-agent, the server may always send > content encoded with gzip or deflate encoding. > > That has been replaced with the section you cite part of.
Received on Friday, 11 April 2014 19:00:06 UTC