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

David Schinazi <> Thu, 16 June 2022 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0956DC157B43 for <>; Thu, 16 Jun 2022 16:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.761
X-Spam-Status: No, score=-7.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jbu5q6ihqdrR for <>; Thu, 16 Jun 2022 16:26:45 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id BF9D6C157B3A for <>; Thu, 16 Jun 2022 16:26:45 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o1ypt-0006Th-5R for; Thu, 16 Jun 2022 23:23:37 +0000
Resent-Date: Thu, 16 Jun 2022 23:23:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o1yps-0006Sn-4M for; Thu, 16 Jun 2022 23:23:36 +0000
Received: from ([2607:f8b0:4864:20::62e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1o1ypq-0007eY-NF for; Thu, 16 Jun 2022 23:23:36 +0000
Received: by with SMTP id i15so2471542plr.1 for <>; Thu, 16 Jun 2022 16:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iiGSAAcPLlSub3up3AfKqsDM0gXefH6MUJ3h97CEDTc=; b=nl7u5j5sDMogyOsJa4F8HV5/W37DIhTccUUwc7yXbkLV2kPHYT6MygLdVar+AdX3WP cXMjqE4rvQtepIjML6onV3VFAAecy8vcsO3AXF5KO6EBDIbB7SZJO18tQm1eEbsjp5d0 RtX7/lVhA83j1jtyV9E8OxH1cNlsVhtQmVdJTm/vl9uuad7fG7qpPkE3Jlw5ETKc5ev3 kpvHuM7BTlN1VXH6F9WfCFB+k3QbsUZWkAM8v98euAak145fiQKYuBP0RTOCaob3LxYC 3iNQ3zmnNhYUzK61sB0uskc128R5RKT3g3mkgudN14kgEsv7OhmevVXeOFKNo0lJ7I3s Hnhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iiGSAAcPLlSub3up3AfKqsDM0gXefH6MUJ3h97CEDTc=; b=W7PoimSkyrN6L8KLnSY8C4u6WIwRZ/hVvToXlscNDNNvtk+z/+z7L/dL0f8718OMU3 bDSOad47perFHL//HrF1USM3Oi4AudREbj2w1BcU2++0/z0ZZpYlngDqgJd42MCM2BCO Z4mh+rJ1FfhM5qDv7onzIm4X8CHd7r98qEqXJAWg0M/Pf3jA1vu0FR4tk3jKKQvj+pbs p25n2lD71mvAEpkLluRqXK3z8PLQzPt5bB28tUS06B8Gd27RJdwZ0eRgvBcWwGHGoC0V eVXZgEFFQ/j1kEgKtSnheoyyrtRqFD70g2jwJ4JRwnGcgX13ZjugoaeIp47Ybwc8U1VV yHEw==
X-Gm-Message-State: AJIora+mfksEeBphEB/F1F1auK3T0ObAZtUivRF03cwqUi7kRUVJ/v4u 9DG0rKMvHnJ1c8U5I81SEv+omolWmdJCak9Z9os=
X-Google-Smtp-Source: AGRyM1tlkoPU6U87OXDy8kbnJFD/DApgbCExa2nX458JSjLbGVcR1I/fh6AgkjyzQRGUH9Ygk1RtYZf5YgYWOu16zHQ=
X-Received: by 2002:a17:902:8502:b0:16a:34a:e477 with SMTP id bj2-20020a170902850200b0016a034ae477mr1146653plb.40.1655421803363; Thu, 16 Jun 2022 16:23:23 -0700 (PDT)
MIME-Version: 1.0
References: <YqsBZ0M4lDXGRQTo@miskatonic> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 16 Jun 2022 16:23:12 -0700
Message-ID: <>
To: Lucas Pardue <>
Cc: HTTP Working Group <>, Amaury Denoyelle <>, IETF QUIC WG <>, Ryan Hamilton <>
Content-Type: multipart/alternative; boundary="0000000000008b031c05e198ec1b"
Received-SPF: pass client-ip=2607:f8b0:4864:20::62e;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o1ypq-0007eY-NF 54a621f96dcae2738d6a7ce599c80b54
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40136
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.


On Thu, Jun 16, 2022 at 3:26 PM Lucas Pardue <>

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