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

Willy Tarreau <> Fri, 17 June 2022 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6FA8C15D86E for <>; Fri, 17 Jun 2022 10:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.661
X-Spam-Status: No, score=-7.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 8EftTCYeiY28 for <>; Fri, 17 Jun 2022 10:47:54 -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 D2223C157B34 for <>; Fri, 17 Jun 2022 10:47:54 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o2G3n-0005Rn-KD for; Fri, 17 Jun 2022 17:47:07 +0000
Resent-Date: Fri, 17 Jun 2022 17:47:07 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o2G3l-0005Qd-NW for; Fri, 17 Jun 2022 17:47:05 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1o2G3k-00016R-Bt for; Fri, 17 Jun 2022 17:47:05 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 25HHkonp031208; Fri, 17 Jun 2022 19:46:50 +0200
Date: Fri, 17 Jun 2022 19:46:50 +0200
From: Willy Tarreau <>
To: David Schinazi <>
Cc: Lucas Pardue <>, 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: 1o2G3k-00016R-Bt 4aeec141ed8349819a7f61bd06572dc3
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40157
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Jun 17, 2022 at 10:31:39AM -0700, David Schinazi wrote:
> Since it's Friday and we're exploring crazy thoughts, instead of
> ":no-content" why not simply content-length=0?

You're right that it already exists for exactly that purpose and
would work out of the box. And any intermediary will be free to
drop it when converting to H1 for methods that do not use a body
by default, and it could be used as a work-around for those that
for various reasons cannot send the FIN bit.

Then I would suggest that we'd recommend that senders emit the FIN
(or ES in H2 but that's already the case) along with the HEADERS
frame, and that if they're not able to do it, as an alternative
they should explicitly send content-length:0 to inform the recipient
that it must not expect anything else.

I'm pretty sure that we can come up with such a reasonable solution
that can end up as an implementation advice so that we don't put any
implementation into a difficult situation, so let's continue down
that route!