Re: Design Issue: GZIP flag on DATA Frames

[Roberto Peon <[e-mail]>]

I don't see why it is a one or the other choice.

>From a pragmatic viewpoint, we required gzip because it was lacking in a
lot of implementations, or went through a proxy which stripped it.

Requiring that it be supported enabled servers to send the data compressed.
This was essentially the result of years of being frustrated with not
knowing when it was safe to at least be able to send with a baseline
compression.

Unfortunately, gzip isn't the best compressor in the world, so we will
always need since mechanism for negotiating a compression scheme.
Http's scheme works, and many of its flaws are unavoidable in any system
with proxies.

Having played with compression at the protocol layer, my experience is that
it adds complexity where it is often not warranted and it results in (at
best )awkward apis.

-=R
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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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:[e-mail] ·
http://bjoern.hoehrmann.de
>> > Am Badedeich 7 · Telefon: [phone] ·
http://www.bjoernsworld.de
>> > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>> >
>>
>