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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 11 Apr 2014 18:51:55 +0200
Message-ID: <53481DAB.9050904@gmx.de>
To: Martin Thomson <martin.thomson@gmail.com>, Roland Zink <roland@zinks.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-04-11 18:41, Martin Thomson wrote:
> On 11 April 2014 09:17, Roland Zink <roland@zinks.de> wrote:
>>> 2. It's a very late stage to be adding features.
>>
>> Mandating C-E gzip was added lately and actually this causes some problems
>> which may be solved be T-E.
>
> C-E gzip (and maybe deflate) have been in the spec since the
> beginning.  The recent change was to remove the mandate for C-E
> deflate (which might not have been a mandate due to confusing text).
>
>> Actually why is C-E better here than T-E? Especially as existing proxies do
>> C-E on the fly.
>
> That's not a good idea.  For the aforementioned reason, and for other
> reasons including having to re-mint ETags without coordination with
> the origin server.

But don't we have that problem already (ack: K.Morgan@iaea.org):

"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"." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-http2-11.html#rfc.section.9.3.p.2>

What are these intermediaries supposed to do with the ETag?

Best regards, Julian
Received on Friday, 11 April 2014 16:52:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:25 UTC