W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 24 Mar 2014 13:42:59 -0700
Message-ID: <CABkgnnUWosRLhNSq0TjVrw2PfDzQkPvSY0SEjJjqBu0KrR8NpQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, K.Morgan@iaea.org, HTTP Working Group <ietf-http-wg@w3.org>
On 24 March 2014 13:19, Roy T. Fielding <fielding@gbiv.com> wrote:
> It seems you have confused them.

Let's take the "seems" out of that, I did confuse them.  And it is not
the first time that has happened in this area.

> If HTTP/2 doesn't allow compression transfer encodings, then it doesn't
> allow compression by intermediaries. I assumed that TE was replaced by
> a framing mechanism that indicates the payload has been compressed.
> If that isn't so, then HTTP/2 will be less efficient than HTTP/1 for
> some use cases (like CDNs).

We had a long series of discussions on this point.  It may be that we
failed to trigger the necessary reactions from folks at the time and
this needs to be reopened.  I will not attempt to defend the process
we took.

0. SPDY had a frame to indicate that frames were compressed
http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.2.2

1. it was removed after some discussion:
https://github.com/http2/http2-spec/issues/46
http://http2.github.io/http2-spec/#changes.since.draft-ietf-httpbis-http2-01
(point 2; -01 was 2013-01 FYI)

2. we discussed it more on-list
http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0865.html
Received on Monday, 24 March 2014 20:43:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC