Re: H2 vs HPACK header table size... again

On Wed, Dec 22, 2021 at 04:11:44PM +0100, Willy Tarreau wrote:
> 
> And I think this is where there are two different readings which possibly
> depend on how the implementation is built:
> 
>   - if you write some client code, it seems natural that HPACK is
>     instantiated before the H2 layer, and in this case I wouldn't be
>     surprised that the "initial" term used above is interpreted as
>     "first set your HPACK default value to 4096 and announce it if
>     you learn otherwise, including from the H2 SETTINGS frame",
>     which seems to be how Tatsuhiro and Pat have interpreted it in
>     the thread below (do not hesitate to correct me, I'm not trying
>     to put words in your mouth at all):
> 
>       https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0586.html
> 
>   - if you're writing some server code, it seems natural that H2 is
>     instanciated before HPACK and that HPACK comes with the negotiated
>     settings. After all we could even imagine a SETTINGS parameter to
>     switch to a totally different encoder. In this case HPACK starts
>     with an initial value that matches the one advertised by the client,
>     which seems to be what Cory, Hervé and I have interpreted in the
>     thread below:
> 
>       https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0107.html

My experience on this matter (having written server end) is that for
interoperability, the server has to support at least 4kB receive window.
I did not test many clients, but I saw at least Curl failing hard.

The implementation uses 0 send window, and unconditionally sends the
command to zero window in front of every HEADERS frame. Does not seem
to cause problems (and I have seen much more obscure issues).

> I do not care about systematically emitting one extra byte to update
> a table size that we already know if that improves interoperability,
> but I find it pretty annoying that 6 years later we continue to face
> interoperability issues because there seem to be two incompatible
> readings of this corner case of the spec. And I suspect that the issue
> also exists for situations where a large SETTINGS_HEADER_TABLE_SIZE
> value is emitted by the decoder, the encoder is not willing to change
> from 4kB and stays at 4kB, but the decoder assumes that the encoder
> agreed with the initially advertised one. This can be worse because
> it could work without triggering compression errors but possibly
> result in damaged messages.

IIRC, HPACK numbers headers from newest to oldest, which guarantees that
mismatched window size can never result in correctly compressed messages
to be silently misdecompressed.


-Ilari

Received on Thursday, 23 December 2021 13:23:50 UTC