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

Willy Tarreau <> Fri, 17 June 2022 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78CF1C15AAEC for <>; Fri, 17 Jun 2022 03:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vJfatN5urBYb for <>; Fri, 17 Jun 2022 03:49:16 -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 51662C15AAE6 for <>; Fri, 17 Jun 2022 03:49:16 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o29XJ-0008Ic-Ba for; Fri, 17 Jun 2022 10:49:09 +0000
Resent-Date: Fri, 17 Jun 2022 10:49:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o29XI-0008Hj-DJ for; Fri, 17 Jun 2022 10:49:08 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1o29XG-0005eB-Oq for; Fri, 17 Jun 2022 10:49:08 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 25HAmrOq030739; Fri, 17 Jun 2022 12:48:53 +0200
Date: Fri, 17 Jun 2022 12:48:53 +0200
From: Willy Tarreau <>
To: Lucas Pardue <>
Cc: Martin Thomson <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o29XG-0005eB-Oq e8bee3f6b4f4b6b865d1a87399c58c3a
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40154
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Lucas,

On Fri, Jun 17, 2022 at 11:41:43AM +0100, Lucas Pardue wrote:
> Which leads me to a wild thought*. One could attempt to solve this problem
> in the HTTP framing layer, by introducing, via extension, a new
> pseudo-header ":no-content", which modifies the message exchange sequence
> in H2 and H3 such that no DATA frames are allowed after the first flight of
> header section. That solves the disjoin between the headers section and the
> ES flag or FIN bit. And would allow the receiving peer to make more
> concrete choices about whether to process a request early or wait a bit.

I think that it's an excellent idea to explore! The pseudo-header fields
were created to fill a gap and this is a perfect example of such a gap
where the HTTP framing doesn't sufficiently permit an agent to express
its intent anymore, and your proposal addresses this. The only thing is
that if we wanted to do something clean, it would have to be advertised
with the vast majority of GET requests, which is unlikely to happen in
the foreseable future. Regardless, I think it's worth continuing to
think around this.

> * It's Friday, so it's the day of the week I'm allowed to have these :-P

You're right ;-)