Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement

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
>>>
>>>