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