W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

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

From: Martin Thomson <mt@lowentropy.net>
Date: Thu, 23 Dec 2021 16:21:01 +1100
Message-Id: <ec4a1bdf-45a8-4287-8d3f-bfe85608f8b1@www.fastmail.com>
To: "Willy Tarreau" <w@1wt.eu>
Cc: ietf-http-wg@w3.org
On Thu, Dec 23, 2021, at 15:08, Willy Tarreau wrote:
>> * A server rarely has a situation where the initial value is needed as it
>> always has the value from the client preface, but it has to send the SETTINGS
>> ACK and size change instruction anyway, unless the client retains the 4k
>> initial value.
> That's the delicate point in my opinion, where not sending anything means
> something different for the client.

Yeah, this is the key point, but if you consider the possibility that a server might send a response before acknowledging the client's SETTINGS.  This isn't something that makes a lot of sense as the server cannot process a request before it processes the SETTINGS, so reordering the SETTINGS ACK with the response would be...bizarre, but the protocol is designed to allow for that.

Why would the protocol allow for that?  In its current form, it makes little sense because the server never sends headers without a request.  However, if you think of a server using HPACK to send non-trivial metadata to a client, something that is possible with TLS 1.3 (0.5-RTT data seems to be the term we've settled on for that data), then it makes a *tiny* bit of sense.  

Or, you could imagine using that 0.5-RTT data to prime the HPACK header table with useful values (Server, or other common values could be a good use of the bandwidth).  Priming the table is something that might also be a good use of 0-RTT, which would allow a client to use the space even when it doesn't have any requests that might be safe to send.

(Now I almost want to write a draft for that priming idea; HTTP/3 has it already, but it could still help in HTTP/2.)

>> Tatsuhiro's interpretation here matches my own, I think:
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0499.html
> Thanks for sharing! And Tatsuhiro's description there confirms my
> suspicion that the interpretation of the spec depends a lot on which
> side you are developing, that's particularly bad for a spec.

I don't think so, though I think that server implementers are in a position where the normative behaviour isn't ideal, so this is a point that could be clearer.

The big question for me is whether a post-WGLC change is appropriate if we wanted to fix this in h2bis.  We're in IESG processing, so we could probably sneak something in.  How about this:


As I note in the pull request, this might have been better in a revision to RFC 7541, but we don't have that document open and you have to deal with the integration of the two pieces somewhere.
Received on Thursday, 23 December 2021 05:21:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 23 December 2021 05:21:22 UTC