Re: current HTTP/2 spec prevents gzip of response to "Range" request from Martin Thomson on 2014-03-25 (ietf-http-wg@w3.org from January to March 2014)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 25 Mar 2014 11:45:22 -0700
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, K.Morgan@iaea.org, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CABkgnnWTh_yf+trc0L3aS_e4Z_r0XwC4GVmm0on-C-i48ycgxg@mail.gmail.com>

I think that pinning your hopes for "Transfer-Encoding: gzip" on
HTTP/2 might be a little too optimistic, particularly for secure
channels: making decisions that depend on knowing provenance is much
harder when said provenance is several degrees removed.

But the marginal value of this new feature seems insufficient to
justify the feature, even if that new feature is just one we decided
not to port from HTTP/1.1.

On 25 March 2014 11:23, Roy T. Fielding <fielding@gbiv.com> wrote:
> Implementations communicating on a secure channel MUST NOT generate
> dynamically compressed content that includes both confidential data
> and attacker-controlled data unless separate compression dictionaries
> are used for each source of data.

Yep, that is better.

Received on Tuesday, 25 March 2014 18:45:50 UTC