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):
>   - 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:

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.


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