Re: Design Issue: GZIP flag on DATA Frames

If that's the case, and it's better to just handle data compression at
the higher levels, then the requirement that gzip MUST always be
supported independent of what is specified by the accept-* header
ought to be removed and implementations ought to just continue letting
the application decide which mechanism is best.

My goal here is to simplify things wherever possible. If we can
deprecate (or greatly simplify) accept-/transfer-/content-encoding at
the semantic layer and just say that the framing layer will handle
compression, then that's one less optional bit of complexity that us
application-level developers have to deal with.

On Tue, May 21, 2013 at 2:36 PM, Roberto Peon <grmocg@gmail.com> wrote:
> The proposal does force anything other than gzip to use an alternate code
> path for parsing/interpretation, which does not inspire confidence given my
> experience with backup-generator problems, and it probably involves writing
> *more* code today than the alternative of leaving it where it is in the HTTP
> semantic layer.
> -=R
>
>
> On Tue, May 21, 2013 at 2:24 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> This does not preclude the use of alternative compression schemes. If
>> someone chooses, it would be possible, for instance, to continue using
>> accept-/content-/transfer-encoding at the http semantic layer and
>> simply not set the GZIP flag on the DATA frame. Having the GZIP flag
>> would just provide an approach that would make that unnecessary in the
>> most common cases today. If, at some point in the future a new, more
>> efficient better compression algorithm overtakes gzip as the
>> predominant mechanism, the protocol can be updated to reflect that
>> fact (i.e. with a new protocol version string, etc).
>>
>> On Tue, May 21, 2013 at 2:17 PM, Bjoern Hoehrmann <derhoermi@gmx.net>
>> wrote:
>> > * Poul-Henning Kamp wrote:
>> >>You forgot half the "worth-while" part:  The compatibility issues.
>> >>
>> >>Even something as trivial as "deflate" vs. "gzip" was too hard for
>> >>some people to get right.
>> >
>> > I think people will create an even bigger mess if they're forced to work
>> > around lack of support for alternative compression schemes in HTTP/2.0.
>> > --
>> > Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>> > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>> >
>>
>

Received on Tuesday, 21 May 2013 22:08:23 UTC