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

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