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

Re: Negotiating compression

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Sun, 1 Jun 2014 16:31:53 +1000
Message-ID: <CACweHNBRCVgu_j41CZQxZBjwks6G43XgeNp7wqOnGdZMV8H+RA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 1 June 2014 15:30, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 31/05/2014 6:04 a.m., Roberto Peon wrote:
> > The huffman design (using canonical huffman) was chosen such that
> replacing
> > the table would be cheap (as transmitted on the wire), if, in the
> > far-future it is needed to change tables, it will be cheap/possible.
> > That is something to play around with, but not something that I'd guess
> > would fit in the protocol today, as it has uncertain security
> ramifications.
> As a result we need a halfway operation to prevent the existing huffman
> table being used. The best proposal for that so far is the
> disable-huffman SETTING. Which downgrades it from the existing table to
> none rather that changing to an arbitrary alternative table.
> The simplicity gained for naive implementations is an added bonus.
> Amo
I assume the default behaviour would be to use HPACK, and the setting would
disable it. ​Because a client is allowed to send requests without waiting
for the server's settings (§3.5) would it be alright for the server to
respond with RST_STREAM(REFUSED_STREAM) to any streams with compressed
headers that arrive before the ACK? Or does REFUSED_STREAM imply that
headers have passed through/modified the HPACK context before being
refused? In this case we don't want to tear down the connection with a
COMPRESSION_ERROR;  if REFUSED_STREAM is inappropriate, perhaps we could
use RST_STREAM(COMPRESSION_ERROR) to signal that it was refused *before*

Incidentally, as an editorial issue, I'd personally appreciate some text
that clearly states whether REFUSED_STREAM comes before or after HPACK. It
says "prior to any processing", does that include HPACK?

  Matthew Kerwin
Received on Sunday, 1 June 2014 06:32:23 UTC

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