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

Roland Zink <roland@zinks.de> Wed, 26 March 2014 18:21 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 D9AB41A0333 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 26 Mar 2014 11:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 7D7AlrEinBuX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 26 Mar 2014 11:20:58 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52B1A0303 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 26 Mar 2014 11:20:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1WSsQ7-0006dB-Im for ietf-http-wg-dist@listhub.w3.org; Wed, 26 Mar 2014 18:19:23 +0000
Resent-Date: Wed, 26 Mar 2014 18:19:23 +0000
Resent-Message-Id: <E1WSsQ7-0006dB-Im@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 1WSsPt-0006ZY-U4 for ietf-http-wg@listhub.w3.org; Wed, 26 Mar 2014 18:19:09 +0000
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <roland@zinks.de>) id 1WSsPr-0007vX-CX for ietf-http-wg@w3.org; Wed, 26 Mar 2014 18:19:09 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1395857925; l=15746; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=kNMzQ17PiqOAbAz9ZG7FHey74Wg=; b=O6dd2SEQRBk4Zt5ZtlJpkl6FvrTFIfQXKedFrRVYAmJK6/6Dbkz59l7Ne1YwanUNJnq 0EOvAjrK3H15ffVl2ZzLjGWkD7JmD1jswQ5VmT3FNngpZp4Nu5M0rwEudUVoHVPrvPj/g IL/lhXGda3UlZn0s/+M0Z26sPyOazBinEcc=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIl+wls/iszpYYtJo07Db95+Xx/A==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:9597:9b6c:a9db:e47f] ([2001:4dd0:ff67:0:9597:9b6c:a9db:e47f]) by smtp.strato.de (RZmta 32.31 AUTH) with ESMTPSA id C0549eq2QIIiEzn (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for <ietf-http-wg@w3.org>; Wed, 26 Mar 2014 19:18:44 +0100 (CET)
Message-ID: <53331A05.2060502@zinks.de>
Date: Wed, 26 Mar 2014 19:18:45 +0100
From: Roland Zink <roland@zinks.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <0356EBBE092D394F9291DA01E8D28EC20100F3AB51@sem002pd.sg.iaea.org> <CABkgnnUQWFT932map4DDCqxLpXxSL=1EeauTDSjsvHSxrT0pug@mail.gmail.com> <q8o0j9picqc6ode3v9v3g1uqgtd5dhi02q@hive.bjoern.hoehrmann.de> <CABkgnnUjXGNedAi4miJ7V3bFtMBEfkGTb8HLf7QsC6uY=zTjUg@mail.gmail.com> <C48420EB-9297-40A9-BD92-D08057E42439@gbiv.com> <0546C0B5-EE2C-4430-B6A7-CAB7AF904623@mnot.net> <D24915E7-E546-4A05-A7A3-8DE75CD06696@gbiv.com> <0356EBBE092D394F9291DA01E8D28EC20100F3EA35@sem002pd.sg.iaea.org>
In-Reply-To: <0356EBBE092D394F9291DA01E8D28EC20100F3EA35@sem002pd.sg.iaea.org>
Content-Type: multipart/alternative; boundary="------------060809040903090201030008"
Received-SPF: none client-ip=81.169.146.162; envelope-from=roland@zinks.de; helo=mo4-p00-ob.smtp.rzone.de
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.103, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1WSsPr-0007vX-CX 17209929939ac25c5d1b8c75e274cbd9
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/53331A05.2060502@zinks.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/22937
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>

I like the idea of requiring transfer encoding instead of content 
encoding but I have concerns regarding replacing content-encoding by 
transfer encoding. When a 200 response is forwarded to a 1.1 client by 
an intermediary as content-encoding then the gzipped content is the 
same. However in HTTP/1.1 with content-encoding the gzipped content is a 
different entity than the not gzipped. If the client make further 
requests based on the content received then it will use the ETag from 
the server (for the uncompressed content) or one invented by the 
intermediary (for the compressed content). In both cases something may 
go wrong on further requests, for example a cache validation may fail. 
For a followup range request this would mean that the client does it on 
the compressed content and the server will assume the range is for the 
uncompressed content and the wrong range will be returned.

This gets especially complicated if it is assumed that the client is 
roaming between networks and cache partial responses.

Maybe something like this may work:

9.3 GZip Transfer-Encoding

Clients MUST support gzip compression for HTTP response bodies. 
Regardless of the value of the TE request header field, a server MAY 
send responses with gzip transfer encoding. A compressed response MUST 
still bear an appropriate transfer-encoding header field. This 
effectively changes the implicit value of the TE header field 
([HTTP-p2], Section 14.39) from "chunked" to "gzip, chunked". Clients 
SHOULD not include the values "gzip" or "deflate" in a Accept-Encoding 
header. Intermediaries translating from HTTP/1.1 to HTTP/2 SHOULD 
forward the Accept-Encoding header. If there is an Accept-Encoding 
header containing gzip as value then servers MAY use gzip 
Content-Encoding instead of gzip Transfer-Encoding.



Mandating content-encoding gzip has the same issue as it is not mandated 
in HTTP/1.1 and a gateway can't really translate.

Regards,
Roland


On 25.03.2014 20:16, K.Morgan@iaea.org wrote:
>
> Based on the feedback from the group thus far we have written up a 
> proposed replacement for section "9.3 GZip Content-Encoding". Our 
> proposal is based on using gzip transfer encoding. We are proposing 
> this route because, as Matthew pointed out, it allows more freedom 
> than a flag which is forever locked to gzip.
>
> **NOTE: We believe our proposal still maintains backwards 
> compatibility with the poor misused/abused Content-Encoding prevalent 
> in HTTP/1.1**
>
> > On 25 Mar 2014, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> > just stop calling it content encoding. It is not the same thing.
>
> We couldn't agree more!
>
> Here is our proposal...
>
> 9.3 GZip Transfer-Encoding
>
> Clients MUST support gzip compression for HTTP response bodies. 
> Regardless of the value of the TE request header field, a server MAY 
> send responses with gzip transfer encoding. A compressed response MUST 
> still bear an appropriate transfer-encoding header field. This 
> effectively changes the implicit value of the TE header field 
> ([HTTP-p2], Section 14.39) from "chunked" to "gzip, chunked". Servers 
> SHOULD not use gzip transfer encoding if the requested content is 
> already compressed (e.g. images, videos, compressed files, etc.). 
> Servers MUST not include the values "gzip" or "deflate" in a 
> Content-Encoding header, regardless of whether the requested content 
> is already compressed, but SHOULD include the appropriate mime type in 
> the Content-Type header. Correspondingly, clients SHOULD not include 
> the values "gzip" or "deflate" in a Accept-Encoding header.
>
> The following rules apply to intermediaries that perform translation 
> from HTTP/2 to HTTP/1.1:
>
> 1) if the request does not include an Accept-Encoding or TE header 
> that includes the value "gzip", the intermediary MUST decompress the 
> payload,
>
> 2) if the request includes an Accept-Encoding header that includes the 
> value "gzip", but does not include a TE header that includes the value 
> "gzip",
>
>    a) the intermediary MUST decompress payloads that are gzip transfer 
> encoded and have a :status header value of "206",
>
>    b) the intermediary SHOULD not decompress payloads that are gzip 
> transfer encoded and have a :status header value not "206", and if the 
> intermediary elects to keep the payload compressed, MUST remove the 
> value "gzip" from the Transfer-Encoding header and insert the header 
> "Content-Encoding: gzip" in order to maintain backwards compatibility 
> with HTTP/1.1 clients,
>
The vary header should be set to include accept-encoding. What to do 
with a potential ETag?
>
> 3) if the request includes a TE header that includes the value "gzip", 
> the intermediary SHOULD not decompress the payload.
>
> Clients, servers and intermediaries MAY elect to support other 
> compression methods for transfer encoding, in which case it MUST be 
> explicitly requested by the client in the TE header.
>
> Keith Morgan & Christoph Brunhuber
>
> --
>
> Keith S. Morgan
>
> Remote Monitoring Unit
>
> Safeguards, International Atomic Energy Agency (IAEA)
>
> Vienna, Austria
>
> Office: +43 1 2600 26672
>
> Handy: +43 699 165 26672
>
> 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.
>