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: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 17 Jun 2022 10:31:39 -0700
Message-ID: <CAPDSy+59E4MJ+OkEEEUN_XykEg8qy7AQPTUs5J0XuKOhomCXLQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
Since it's Friday and we're exploring crazy thoughts, instead of
":no-content" why not simply content-length=0?
David

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:32:03 UTC

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