Re: Design Issue: GZIP flag on DATA Frames

James, I think the existing spec language is fine. Its there based on
implementation experience (which has been collected in scenarios with no
implicit accept-encoding, as well as early spdy versions that applied gzip
on a spdy frame basis, along with incantation in there now which has worked
well imo) - you're sort of frenetically re-enacting the entire history of
the feature's many changes all in one day.

The way it is, the skids are greased for deflate as a LCD and the door is
open in the usual way to other approaches.


On Tue, May 21, 2013 at 6:07 PM, James M Snell <jasnell@gmail.com> wrote:

> 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/
> >> >
> >>
> >
>
>