Instead of assuming chunked encoding in this case, an intermediary could delay sending the request until it either receives the QUIC FIN, or receives an HTTP/3 DATA frame, right? (Though admittedly, that is a potentially performance hit). Now that HTTP/3 is RFC 9114, I suspect it's too late to add new normative language.
Cheers, Ryan On Thu, Jun 16, 2022 at 3:08 PM Amaury Denoyelle <[email protected]> wrote: > Hello, > > I have read HTTP/3 specification and I do not find any requirement on > setting the FIN bit of a QUIC STREAM frame which contains a H3 HEADERS > if the request does not have a body. > > For me, it represents an ambiguity on the internal HTTP message > representation. If no content-length header is present, it could be > interpreted as equivalent to HTTP/1.1 chunked transfer encoding. This > ambiguity could be removed by requiring the STREAM FIN bit set for the > frame containing H3 HEADERS if no body is present. If instead it's > preferable to maintain a separation between HTTP/3 and QUIC, maybe a new > H3 internal mechanism could be implemented to signal the end of a stream > without a body. > > I think this issue is particularly important for intermediaries, such as > haproxy. Currently, when receiving a H3 HEADERS frame from a client > without the underlying STREAM FIN bit set, we generate for the server a > HTTP/1.1 message with a chunked transfer encoding body. This is to > ensure that we do not discard any possible arriving H3 DATA frames > after. However, a lot of HTTP servers are stricter with the presence of > a body and will for example reject GET requests with a chunked transfer > encoding. > > Please let me know your thoughts on the subject, > Regards, > > -- > Amaury Denoyelle > >
