W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

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

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 16 Jun 2022 23:25:48 +0100
Message-ID: <CALGR9obvYB-2vYXYgwSMpS3s8uSbLKn0ZF39piYQ_ROt8DAXJg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Amaury Denoyelle <adenoyelle@haproxy.com>, IETF QUIC WG <quic@ietf.org>, Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
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