Hi Amaury, + the HTTP WG list, since they now own HTTP/3 and in case there are folks over there not watching QUIC closely. On Thu, Jun 16, 2022 at 11:23 PM Ryan Hamilton <rch= 40google.com@dmarc.ietf.org> wrote: > 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 <adenoyelle@haproxy.com> > 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 >> >>Received on Thursday, 16 June 2022 22:26:15 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC