Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement

Some very interesting points here, can't respond to all of them due to time
constraints.

On Fri, Jun 17, 2022 at 11:20 AM Willy Tarreau <w@1wt.eu> wrote:

>
> But given that we're still in the early days of such implementations, I'd
> rather see the pieces arrange correctly so that everything works as
> smoothly
> as it can. That's why if there's no strong objection against this, I'd file
> an errata to at least mention the issue and how to best deal with it from
> both sides, so that newcomers have a chance to notice it before they're
> engaged too deeply with their code.
>

The discussion illustrates there are several considerations around the
handling of translation between versions. Perhaps a lengthier piece of text
in an I-D that treats them all might be worth a consideration.

Which leads me to a wild thought*. One could attempt to solve this problem
in the HTTP framing layer, by introducing, via extension, a new
pseudo-header ":no-content", which modifies the message exchange sequence
in H2 and H3 such that no DATA frames are allowed after the first flight of
header section. That solves the disjoin between the headers section and the
ES flag or FIN bit. And would allow the receiving peer to make more
concrete choices about whether to process a request early or wait a bit.

Cheers
Lucas

* It's Friday, so it's the day of the week I'm allowed to have these :-P