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

Lucas Pardue <> Thu, 16 June 2022 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF9E5C15AACA for <>; Thu, 16 Jun 2022 15:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Status: No, score=-2.76 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_BLOCKED=0.001, 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 bQ6HHcddi6u0 for <>; Thu, 16 Jun 2022 15:29:49 -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 29B73C14CF18 for <>; Thu, 16 Jun 2022 15:29:48 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o1xwP-000610-GV for; Thu, 16 Jun 2022 22:26:17 +0000
Resent-Date: Thu, 16 Jun 2022 22:26:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o1xwN-0005zn-Ck for; Thu, 16 Jun 2022 22:26:15 +0000
Received: from ([2607:f8b0:4864:20::f2e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1o1xwK-00088e-Mi for; Thu, 16 Jun 2022 22:26:15 +0000
Received: by with SMTP id u8so4153009qvj.2 for <>; Thu, 16 Jun 2022 15:26:12 -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=vpDcr24nEBTflzAT1uxfn2HipFbzGzY8mXbW413TVHI=; b=Dm6Co/rifOFtz/sN4wpgteJSIGkacji+f3DQSicbFdjk7rturk0JFVTQkVIC+htL8R qgcrkN6rtlk5JQqlhmoKBdbsN15dQTa2fbkDKVaRsHidDX9rnsiSgnAkZ2RrigLwE14e 1ACV0djXphpTlnQXLcNCSAg+prJeyHXj9txV++WbN0YR0/qv0QUyep7BY5H573OiOv2o 7EnRiowoyobUkc4kotwhLOAXnSqg8HazZf77qiX0BTzP7yY2R7h14Lk5+K84aMZNdcyB pXFS6WhRyHJzynAjYfG0K1C9+SvNHwSyZjl+Z+6weN6n5KZ+vG0Fa3hZHgrFDIoqUclV Dz/w==
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=vpDcr24nEBTflzAT1uxfn2HipFbzGzY8mXbW413TVHI=; b=xxbCA51aYQuVDaVVw8CzsGWXgTUkoOpIzPgSJRCKlYgfLIO+773ooSupgKcZEg5m8F 5+PzVLRigNpZP/0SP2I5h+bUgWNjp0wEvRVGQYCBiP7poV2oQmwLuCCc+8SYkYbILnGx AruWYQTylnBcnekSp5I9O16niP2/MaXIgTmAtzwAyS30bs1Bpkkj4caJu8ZUnIEdwkyh 1DYX05XL3ekPYOIjkGxdTvOvW0O4vNOq1unL9Z6CNpvkrtomLRlkAtbt6YYazDmBCiJs qOhXbPC4lKsUH4oNQDP6JIrp86RM+feKk0jTF4jyA2vkklqowmKwDVSXd3ABkyIJoUIt 9Pow==
X-Gm-Message-State: AJIora8FYtl/U2BNBk3JVerHD8/A2NjiuNXnG+weBqKuiZPQseKQ9ziE be7FHZAWI7irUu/NTqs0WW7aNmpLXYxD0g2Yn2JHxv4Q
X-Google-Smtp-Source: AGRyM1tw4a9Vo4leA+oRwkhhySQol9dTmmHIF1amHrW62SNsJ55Wia0N+Dq3epQcajt6KzyeFjH9TkYH/CjsPTn0elg=
X-Received: by 2002:ad4:5bae:0:b0:46b:8c02:5dbc with SMTP id 14-20020ad45bae000000b0046b8c025dbcmr6201987qvq.94.1655418360804; Thu, 16 Jun 2022 15:26:00 -0700 (PDT)
MIME-Version: 1.0
References: <YqsBZ0M4lDXGRQTo@miskatonic> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 16 Jun 2022 23:25:48 +0100
Message-ID: <>
To: HTTP Working Group <>
Cc: Amaury Denoyelle <>, IETF QUIC WG <>, Ryan Hamilton <>
Content-Type: multipart/alternative; boundary="00000000000059b82505e1981f85"
Received-SPF: pass client-ip=2607:f8b0:4864:20::f2e;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Scan-Sig: 1o1xwK-00088e-Mi 234ccbb001888e529251872e3565ee29
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40134
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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