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

On Thu, Dec 23, 2021 at 04:21:01PM +1100, Martin Thomson wrote:
> 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.

I didn't even think about that, indeed. But there's indeed little use for
this, though I can imagine that some implementers might have to face this
difficult choice.

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

You love to write drafts ;-)

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

No, to be clear, there's no ideal or not ideal, it's a matter of translating
what we read into code. My reading of the spec (initially as a server
implementer) makes it very clear that I do *not* have to do that. But
rereading it with my mind arranged as a client implementer makes me think
that it makes sense that it is needed. This is why I raised the issue
again. When the problem reporter told me that he worked around the
problem by sending this 0x20 byte, I was worried about the risk of
breaking other implementations that do not expect this to happen
because... it's not how I read the spec. Adapting code to match a spec
is a detail. Adapting code to match one interpretation of a spec is more
of a concern, hence my request to make sure that there cannot be two
interpretations of the spec.

> The big question for me is whether a post-WGLC change is appropriate if we
> wanted to fix this in h2bis.

Yes I know, that's delicate. But we're not changing the spec, just clarifying
something that seems to match a consensus between a majority of implementers.
In any case we're certainly not going to declare them non-compliant after
so many years, whatever side they're currently on. And those who read it
like me (apparently Cory and Hervé did) will likely not have a big
difficulty seeing the other interpretation that most other implementation
already adopted.

> We're in IESG processing, so we could probably
> sneak something in.  How about this:
> 
> https://github.com/httpwg/http2-spec/pull/1003

That looks perfectly balanced to me. It clarifies this gray area without
saying too much about how the compression works. I'm fine with adding that
initial table update with that spec.

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

Yeah that was exactly why I suggested that we could possibly place a note
in h2bis instead.

Many thanks!
Willy

Received on Thursday, 23 December 2021 06:33:35 UTC