Re: Design Issue: GZIP flag on DATA Frames

Roberto Peon <> Wed, 22 May 2013 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B757221F85EF for <>; Tue, 21 May 2013 17:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ywmaSVxShLw6 for <>; Tue, 21 May 2013 17:29:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9136F21F90DF for <>; Tue, 21 May 2013 17:29:28 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uewup-0005FS-Tw for; Wed, 22 May 2013 00:28:27 +0000
Resent-Date: Wed, 22 May 2013 00:28:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uewud-0005Ed-HO for; Wed, 22 May 2013 00:28:15 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UewuY-0001OR-EW for; Wed, 22 May 2013 00:28:15 +0000
Received: by with SMTP id h1so1730533oag.11 for <>; Tue, 21 May 2013 17:27:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gujYxUkcoD1ZBBBfwFAeyPd+nU38VihPaVyaIhZYai8=; b=BlGQNliJDEoNEEOaTQ44EAkto0qOftMEZf92Ml7l6w4+GbslDyJ6yNfw758OEXfU3Y 3rNIHvQed+SfPDfPE+zPLXHwV5EQZJP2y00b9H9bdtcDdh0HWEhPVu+G12UTuwHk7hmx /eYuH9ZSpy8oQygvicXbvPfbDCzh3jF4+C575mmK+7OURpUNJwOrtgEaiE3prDB8+bjq Yoi8tVdbBFMq4q5+Jhdzv9AwhxF3Vv3MizQzI1RVXaOutscnsWctQv2RBrqv5fJCudOl MTkn/u1J/QuHR0LcocUUFNemgw8cYKBlg5XrO+qhG0uLMk0KK9EVtl0Aq/EzgA9SnghX sAzg==
MIME-Version: 1.0
X-Received: by with SMTP id ei7mr3064210obb.102.1369182464495; Tue, 21 May 2013 17:27:44 -0700 (PDT)
Received: by with HTTP; Tue, 21 May 2013 17:27:44 -0700 (PDT)
Received: by with HTTP; Tue, 21 May 2013 17:27:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Tue, 21 May 2013 17:27:44 -0700
Message-ID: <>
From: Roberto Peon <>
To: James Snell <>
Cc: Roland Zink <>, Poul-Henning Kamp <>, Bjoern Hoehrmann <>, "" <>
Content-Type: multipart/alternative; boundary=047d7b2e49706e0f4804dd43a2fb
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.678, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UewuY-0001OR-EW 2504077dbf64b50d290d3a2664d0b96d
Subject: Re: Design Issue: GZIP flag on DATA Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/18084
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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.

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 <> wrote:
> The proposal does force anything other than gzip to use an alternate code
> path for parsing/interpretation, which does not inspire confidence given
> experience with backup-generator problems, and it probably involves
> *more* code today than the alternative of leaving it where it is in the
> semantic layer.
> -=R
> On Tue, May 21, 2013 at 2:24 PM, James M Snell <> 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 <>
>> 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
>> > around lack of support for alternative compression schemes in HTTP/2.0.
>> > --
>> > Björn Höhrmann · ·
>> > Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
>> > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>> >