W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Porting T-E to HTTP/2: Reasons Against

From: Roland Zink <roland@zinks.de>
Date: Fri, 11 Apr 2014 20:59:42 +0200
Message-ID: <53483B9E.5010708@zinks.de>
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 
Julian's message 
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC