- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 17 Jun 2022 10:00:50 +1000
- To: ietf-http-wg@w3.org
David's approach is the ideal one, but there are others that trade some downsides for performance. It is also possible to generate a response to an incomplete request if you are confident that anything that might follow won't change the response. (That's generally true for any HTTP request.) In this case, you have a complete header block and it is a GET request. Though you might get content, you probably won't. Deciding to serve the answer isn't likely to cause problems. It's a tiny gamble, but one with modest costs: if you do get content, then you committed to ignoring it rather than generating an error. You might be able to use RESET_STREAM if you care about signaling an error and the response hasn't already been delivered. The real loss there is that you can't signal at the HTTP layer. All of the above is also true if you only have GET and a URI (which might need Host). If you don't condition the response on the value of any header field, then you can answer before seeing them, the only risk being that you miss something that might have changed your answer. On Fri, Jun 17, 2022, at 09:23, David Schinazi wrote: > Such an intermediary would already need to buffer an incomplete request > (for example when it's received part of the HEADERS frame but not all > of it). Instead of deciding you've received the full GET request at the > end of the HEADERS frame, just decide you've received it when you've > received the QUIC FIN bit. That's what our implementation does. Note > however that this doesn't work with CONNECT so you'll want to make it > method-specific. > > David > > On Thu, Jun 16, 2022 at 3:26 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: >> 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 Friday, 17 June 2022 00:01:23 UTC