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

On Fri, 17 Jun 2022, 18:31 David Schinazi, <dschinazi.ietf@gmail.com> wrote:

> Since it's Friday and we're exploring crazy thoughts, instead of
> ":no-content" why not simply content-length=0?
> David
>

My thinking is that for an H2-to-H2, H3-to-H3 gateway (or some variant),
that  the content-length is optional and explicit declaration of chunked
T-E cannot be relied upon to guess if there's content coming. So a
pseudo-header fills the gap between ndicating an end to request after the
current flight, without having to wait for ES or FIN. Pseudo-headers are
also a property of the frame, so don't risk affecting the end-to-end
message semantic.



> On Fri, Jun 17, 2022 at 3:49 AM Willy Tarreau <w@1wt.eu> wrote:
>
>> Hi Lucas,
>>
>> On Fri, Jun 17, 2022 at 11:41:43AM +0100, Lucas Pardue wrote:
>> > 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.
>>
>> I think that it's an excellent idea to explore! The pseudo-header fields
>> were created to fill a gap and this is a perfect example of such a gap
>> where the HTTP framing doesn't sufficiently permit an agent to express
>> its intent anymore, and your proposal addresses this. The only thing is
>> that if we wanted to do something clean, it would have to be advertised
>> with the vast majority of GET requests, which is unlikely to happen in
>> the foreseable future. Regardless, I think it's worth continuing to
>> think around this.
>>
>> > * It's Friday, so it's the day of the week I'm allowed to have these :-P
>>
>> You're right ;-)
>>
>> Willy
>>
>>