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

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