IETF Logo Mail Archive

Re: Design Issue: GZIP flag on DATA Frames

James M Snell <jasnell@gmail.com> Tue, 21 May 2013 22:09 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D559C1F0D3A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 15:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.49
X-Spam-Level:
X-Spam-Status: No, score=-9.49 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZtdv2uGsd+U for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 15:09:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1621F0D40 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 May 2013 15:09:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UeujT-0001tW-2H for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2013 22:08:35 +0000
Resent-Date: Tue, 21 May 2013 22:08:35 +0000
Resent-Message-Id: <E1UeujT-0001tW-2H@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UeujH-0001mP-TC for ietf-http-wg@listhub.w3.org; Tue, 21 May 2013 22:08:23 +0000
Received: from mail-oa0-f48.google.com ([209.85.219.48]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UeujD-0004Ae-7r for ietf-http-wg@w3.org; Tue, 21 May 2013 22:08:23 +0000
Received: by mail-oa0-f48.google.com with SMTP id i4so1553724oah.7 for <ietf-http-wg@w3.org>; Tue, 21 May 2013 15:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vthx8CTjYquZ4DinS9dlK1f8A25fwIpzfYxsoGsZR2Y=; b=06UMt23WNQ0B6AoFMxxt2jRTCsh4gg7YuVBLr8dgrVphMpt9e49AIJXNUSPggSWUSf 3QuwFRYhKRhbZjw/ICoEhnbxM5Byv+GyH15wEO7w8QQ8Jx9avlpDp8Ug67gbwCZWd50c bCk6eGFCuCiY0v+CqLyEAdU/PWbviPpfMj0L/k0y3k2j9PPyRkckHdPw+Xg4k6EFIhO/ 8Sim5+Seb7hFR/mY7qaWhlb0+VGQ/2DyNd/Fq2jG791qSgzvSmEI+TxtHpK2RA2dKCzv Fx2K4/1lJuhwPildGCnctdM4Ov5QGP//bC26pABhBUD4yc2+8pdEa/uqeFA8P+iC0Iyg akig==
X-Received: by 10.182.129.4 with SMTP id ns4mr2925345obb.22.1369174073047; Tue, 21 May 2013 15:07:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 15:07:32 -0700 (PDT)
In-Reply-To: <CAP+FsNd3gqky+94N3k3rJxiC744+3AU1GhoWc4EHoQDiDip0Mg@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> <CAP+FsNd3gqky+94N3k3rJxiC744+3AU1GhoWc4EHoQDiDip0Mg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 21 May 2013 15:07:32 -0700
Message-ID: <CABP7Rbfvpn-pohq39OBi2xoTkChseDrPkhRGE_VaTEdMmRqTaQ@mail.gmail.com>
To: Roberto Peon <grmocg@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.48; envelope-from=jasnell@gmail.com; helo=mail-oa0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.657, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UeujD-0004Ae-7r 73f6e0592320195b1677db9fb0c9f708
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: GZIP flag on DATA Frames
Archived-At: <http://www.w3.org/mid/CABP7Rbfvpn-pohq39OBi2xoTkChseDrPkhRGE_VaTEdMmRqTaQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18080
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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

v2.23.0 | Report a Bug | By Email