W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

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

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 17 Jun 2022 18:41:56 +0100
Message-ID: <CALGR9oamxk90KX6EttXRTG00PynPXnhiki_59ro6e-Y45EDPoA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Friday, 17 June 2022 17:42:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC