RE: current HTTP/2 spec prevents gzip of response to "Range" request

<K.Morgan@iaea.org> Wed, 26 March 2014 17:07 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC491A01AF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 26 Mar 2014 10:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqkDCZoY5hjG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 26 Mar 2014 10:07:24 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 431BF1A0344 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 26 Mar 2014 10:07:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1WSrIH-0002Ky-8T for ietf-http-wg-dist@listhub.w3.org; Wed, 26 Mar 2014 17:07:13 +0000
Resent-Date: Wed, 26 Mar 2014 17:07:13 +0000
Resent-Message-Id: <E1WSrIH-0002Ky-8T@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <K.Morgan@iaea.org>) id 1WSrI1-0002Ia-CC for ietf-http-wg@listhub.w3.org; Wed, 26 Mar 2014 17:06:57 +0000
Received: from vs-m201.iaea.org ([161.5.6.178]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <K.Morgan@iaea.org>) id 1WSrHw-0007oT-Qh for ietf-http-wg@w3.org; Wed, 26 Mar 2014 17:06:57 +0000
Received: from vs-m2.iaea.org (vs-mail2.iaea.org [172.24.1.27]) by vs-m201.iaea.org (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s2QH6Esl014753; Wed, 26 Mar 2014 18:06:16 +0100
Received: from E1.iaea.org (e1.iaea.org [172.24.0.41]) by vs-m2.iaea.org (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s2QH6Dqd030371; Wed, 26 Mar 2014 18:06:14 +0100
X-Envelope-Sender: K.Morgan@iaea.org
Received: from SEM001PD.sg.iaea.org (161.5.105.92) by E1.iaea.org (172.24.0.41) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 26 Mar 2014 18:06:13 +0100
Received: from SEM002PD.sg.iaea.org ([161.5.105.93]) by sem001pd.sg.iaea.org ([161.5.105.92]) with mapi id 14.01.0438.000; Wed, 26 Mar 2014 18:06:13 +0100
From: K.Morgan@iaea.org
To: matthew@kerwin.net.au
CC: fielding@gbiv.com, derhoermi@gmx.net, roland@zinks.de, C.Brunhuber@iaea.org, ietf-http-wg@w3.org
Thread-Topic: current HTTP/2 spec prevents gzip of response to "Range" request
Thread-Index: Ac9JFbC8b45buDrMTYuVqAFZw3hb6A==
Date: Wed, 26 Mar 2014 17:06:12 +0000
Message-ID: <0356EBBE092D394F9291DA01E8D28EC20100F3F43F@sem002pd.sg.iaea.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.5.105.94]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20592.000
X-TM-AS-Result: No--11.745000-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20140326 #7649090, check: 20140326 clean
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20140326 #7655388, check: 20140326 clean
X-Scanned-By: MIMEDefang 2.73
Received-SPF: pass client-ip=161.5.6.178; envelope-from=K.Morgan@iaea.org; helo=vs-m201.iaea.org
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-2.104, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.389, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1WSrHw-0007oT-Qh 62297efcecdaf86b7e0a498be6892a61
X-Original-To: ietf-http-wg@w3.org
Subject: RE: current HTTP/2 spec prevents gzip of response to "Range" request
Archived-At: <http://www.w3.org/mid/0356EBBE092D394F9291DA01E8D28EC20100F3F43F@sem002pd.sg.iaea.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/22935
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>

Hi Matthew-

On Wednesday,26 March 2014 05:06, Matthew Kerwin wrote:
> That said, I'm pretty strongly for supporting the negotiation in the first place.
> Maybe it needs to be something that's clearly a part of HTTP/2, freeing it from the
> stigma attached to the existing TE/Transfer-Encoding headers.

That would work too. We aren't married to the idea of using the TE/Transfer-Encoding headers. We just thought the trickle-down effect (to quote Ronald Reagan) might be beneficial.  If clients (e.g. browsers) support HTTP/2, then they would have to support TE.  Once browsers support TE then slowly HTTP/1.1 servers might start supporting Transfer-Encoding.

> After much deliberation I have a crazy idea: introduce a new frame type for hop-by-hop headers.
> I can think of a couple of benefits:
> * It would be easier to clearly distinguish hop-by-hop and end-to-end concerns (e.g. hopefully help clear up some of the CE/TE confusion).
> * It would provide more flexibility than, say, a settings parameter or a flag in a data frame, by allowing the same type of coding negotiation currently allowed in HTTP.
> * It would be extensible, allowing experimental headers, not unlike HH from [draft-nottingham-http-browser-hints-05].
> * It also makes it easier for people to ignore them ;)

I think we'd be happy with Transfer-Encoding, a flag in an existing frame type or an entirely new frame type.

One question though, this idea to use a frame type for _hop-by-hop_ headers seems to contradict what you said on Tuesday,25 March 2014 23:25: "Also, because TE is hop-by-hop I risk some intermediary terminating the compression, possibly negatively impacting my site's responsiveness ..."
Wouldn't the ideal answer be some sort of end-to-end transfer encoding?

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.