Resent-Date: Tue, 21 May 2013 21:37:22 +0000
Resent-Message-Id: <E1UeuFG-0004ob-JI@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CABP7RbfynEZ--QMvyXmsGvqKDv2T9CbVCuBfVexNtmTa5_U_pQ@mail.gmail.com>
References: <CABP7Rbfb92Vxrmxj6fKdt+jpO_Qknq8FRjsu5GZW=17uoi4OFg@mail.gmail.com>
 <519BAB26.2010501@zinks.de> <4050.1369156663@critter.freebsd.dk>
 <fnlnp8t14lal0uk5suouc2uuk3uk4429dt@hive.bjoern.hoehrmann.de>
 <5267.1369169573@critter.freebsd.dk>
 <hnnnp8dgpoliq8ca07n89p6apn41mmu2ta@hive.bjoern.hoehrmann.de>
 <CABP7RbfynEZ--QMvyXmsGvqKDv2T9CbVCuBfVexNtmTa5_U_pQ@mail.gmail.com>
Date: Tue, 21 May 2013 14:36:39 -0700
Message-ID: <CAP+FsNd3gqky+94N3k3rJxiC744+3AU1GhoWc4EHoQDiDip0Mg@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>,
 Poul-Henning Kamp <phk@phk.freebsd.dk>, Roland Zink <roland@zinks.de>,
 "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11c1bc04916aec04dd413ee7
Received-SPF: pass client-ip=209.85.214.176; envelope-from=grmocg@gmail.com;
 helo=mail-ob0-f176.google.com
Subject: Re: Design Issue: GZIP flag on DATA Frames
Archived-At: <http://www.w3.org/mid/CAP+FsNd3gqky+94N3k3rJxiC744+3AU1GhoWc4EHoQDiDip0Mg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--001a11c1bc04916aec04dd413ee7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.
-=3DR


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 wor=
k
> > around lack of support for alternative compression schemes in HTTP/2.0.
> > --
> > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoe=
hrmann.de
> > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernswor=
ld.de
> > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websited=
ev.de/
> >
>
>

--001a11c1bc04916aec04dd413ee7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The proposal does force anything other than gzip to use an=
 alternate code path for parsing/interpretation, which does not inspire con=
fidence given my experience with backup-generator problems, and it probably=
 involves writing *more* code today than the alternative of leaving it wher=
e it is in the HTTP semantic layer.<div style>
-=3DR</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Tue, May 21, 2013 at 2:24 PM, James M Snell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jasnell@gmail.com" target=3D"_blank">jasnell@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This does not preclude the use of alternativ=
e compression schemes. If<br>
someone chooses, it would be possible, for instance, to continue using<br>
accept-/content-/transfer-encoding at the http semantic layer and<br>
simply not set the GZIP flag on the DATA frame. Having the GZIP flag<br>
would just provide an approach that would make that unnecessary in the<br>
most common cases today. If, at some point in the future a new, more<br>
efficient better compression algorithm overtakes gzip as the<br>
predominant mechanism, the protocol can be updated to reflect that<br>
fact (i.e. with a new protocol version string, etc).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Tue, May 21, 2013 at 2:17 PM, Bjoern Hoehrmann &lt;<a href=3D"mailto:der=
hoermi@gmx.net">derhoermi@gmx.net</a>&gt; wrote:<br>
&gt; * Poul-Henning Kamp wrote:<br>
&gt;&gt;You forgot half the &quot;worth-while&quot; part: =A0The compatibil=
ity issues.<br>
&gt;&gt;<br>
&gt;&gt;Even something as trivial as &quot;deflate&quot; vs. &quot;gzip&quo=
t; was too hard for<br>
&gt;&gt;some people to get right.<br>
&gt;<br>
&gt; I think people will create an even bigger mess if they&#39;re forced t=
o work<br>
&gt; around lack of support for alternative compression schemes in HTTP/2.0=
.<br>
&gt; --<br>
&gt; Bj=F6rn H=F6hrmann =B7 mailto:<a href=3D"mailto:bjoern@hoehrmann.de">b=
joern@hoehrmann.de</a> =B7 <a href=3D"http://bjoern.hoehrmann.de" target=3D=
"_blank">http://bjoern.hoehrmann.de</a><br>
&gt; Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 <a href=3D"http://ww=
w.bjoernsworld.de" target=3D"_blank">http://www.bjoernsworld.de</a><br>
&gt; 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 <a href=3D"http://=
www.websitedev.de/" target=3D"_blank">http://www.websitedev.de/</a><br>
&gt;<br>
<br>
</div></div></blockquote></div><br></div>

--001a11c1bc04916aec04dd413ee7--