Re: Design Issue: GZIP flag on DATA Frames

FWIW I agree also wrt C-E, since we have legacy issues that would 
prevent this working properly, although as a replacement for T-E gzip it 
could be an option, and could be quite useful to promote this.

Adrien


------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "James M Snell" <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 28/05/2013 6:19:53 p.m.
Subject: Re: Design Issue: GZIP flag on DATA Frames
>Speaking personally -
>
>I'm -1 on this. The semantics you talk about *are* a property of the 
>content, and you're embedding them in the transport.
>
>
>
>On 22/05/2013, at 2:21 AM, James M Snell <jasnell@gmail.com> wrote:
>
>>  https://github.com/http2/http2-spec/issues/100
>>
>>  Currently the spec includes a requirement that all user-agents MUST
>>  support gzip.. specifically:
>>
>>   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.
>>
>>  If we're going to include this requirement, it makes more sense to do
>>  this at the framing layer rather than the HTTP semantic layer. We can
>>  do so easily by defining a GZIP flag on the DATA frame type. If set,
>>  the payload of the DATA frame is compressed.
>>
>>  Doing so largely eliminates the need for the
>>  accept-/transfer-/content-encoding mechanisms at the http semantic
>>  layer.
>>
>
>--
>Mark Nottingham http://www.mnot.net/
>
>
>
>

Received on Tuesday, 28 May 2013 08:31:08 UTC