Re: Negotiating compression

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*
HPACK.

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
  http://matthew.kerwin.net.au/