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

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.