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 19:53:47 +0200
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F6599937-C271-4068-BC13-CA7ED9FBB28B@zinks.de>
To: Martin Thomson <martin.thomson@gmail.com>
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.






> Am 11.04.2014 um 18:41 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> 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.
> 
I totally agree, but they do it because T-E isn't supported.


Received on Friday, 11 April 2014 17:54:11 UTC

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