Re: Design Issue: GZIP flag on DATA Frames

Roland Zink <roland@zinks.de> Tue, 21 May 2013 17:14 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 19B5421F96F7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 10:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 NZl0Kk0nI00U for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 10:14:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E215E21F8F33 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 May 2013 10:14:28 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ueq88-0000Ms-Al for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2013 17:13:44 +0000
Resent-Date: Tue, 21 May 2013 17:13:44 +0000
Resent-Message-Id: <E1Ueq88-0000Ms-Al@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <roland@zinks.de>) id 1Ueq7x-0000JR-3T for ietf-http-wg@listhub.w3.org; Tue, 21 May 2013 17:13:33 +0000
Received: from mo-p00-ob.rzone.de ([81.169.146.161]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <roland@zinks.de>) id 1Ueq7v-0006s4-PN for ietf-http-wg@w3.org; Tue, 21 May 2013 17:13:33 +0000
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIxrBzs6X+ypftRsLes/KInlMVEQ==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:9dea:d02b:b6d0:de13] ([2001:4dd0:ff67:0:9dea:d02b:b6d0:de13]) by smtp.strato.de (josoe mo19) (RZmta 31.27 AUTH) with ESMTPA id C07011p4LG0ZHA for <ietf-http-wg@w3.org>; Tue, 21 May 2013 19:13:10 +0200 (CEST)
Message-ID: <519BAB26.2010501@zinks.de>
Date: Tue, 21 May 2013 19:13:10 +0200
From: Roland Zink <roland@zinks.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CABP7Rbfb92Vxrmxj6fKdt+jpO_Qknq8FRjsu5GZW=17uoi4OFg@mail.gmail.com>
In-Reply-To: <CABP7Rbfb92Vxrmxj6fKdt+jpO_Qknq8FRjsu5GZW=17uoi4OFg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=81.169.146.161; envelope-from=roland@zinks.de; helo=mo-p00-ob.rzone.de
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1Ueq7v-0006s4-PN ac93d06c2b8e1624816cd83b6e475e07
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: GZIP flag on DATA Frames
Archived-At: <http://www.w3.org/mid/519BAB26.2010501@zinks.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18062
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>

This seem to make the introduction of new compression schemes more complex.

On 21.05.2013 18:21, James M Snell wrote:
> https://github.com/http2/http2-spec/issues/100
>
> Currently the spec includes a requirement that all user-agents MUST
> support gzip.. specifically:
>
>    User-agents MUST support gzip compression.
>    Regardless of the Accept-Encoding sent by
>    the user-agent, the server may always send
>    content encoded with gzip or deflate encoding.
>
> If we're going to include this requirement, it makes more sense to do
> this at the framing layer rather than the HTTP semantic layer. We can
> do so easily by defining a GZIP flag on the DATA frame type. If set,
> the payload of the DATA frame is compressed.
>
> Doing so largely eliminates the need for the
> accept-/transfer-/content-encoding mechanisms at the http semantic
> layer.
>