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

Martin Thomson <> Fri, 17 June 2022 05:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41783C15B249 for <>; Thu, 16 Jun 2022 22:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.758
X-Spam-Status: No, score=-2.758 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, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=gLCwbxAI; dkim=pass (2048-bit key) header.b=Km9v3bNl
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZp8GpUyk0FB for <>; Thu, 16 Jun 2022 22:03: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 5E8AEC14F5E1 for <>; Thu, 16 Jun 2022 22:03:41 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o248s-0002wu-0d for; Fri, 17 Jun 2022 05:03:34 +0000
Resent-Date: Fri, 17 Jun 2022 05:03:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o248r-0002vx-1O for; Fri, 17 Jun 2022 05:03:33 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o248p-0002DA-FN for; Fri, 17 Jun 2022 05:03:32 +0000
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C1B003200986; Fri, 17 Jun 2022 01:03:17 -0400 (EDT)
Received: from imap41 ([]) by compute3.internal (MEProxy); Fri, 17 Jun 2022 01:03:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1655442197; x=1655528597; bh=/B kAT2lwoDJl8DIX7TQ8zzeCIw4yODjaLH6+Z35l4GY=; b=gLCwbxAI0fhuL7wlYt EGAtlcRcUaY2R/RulDWoAklOrH9tAP23kYDgmo0fnZLyCxjFlwn4vftGNu4f+K9I h1E5XNUhmQmk7EmrjPRUpcdtTMjj/1wULATywLo4DtxRcFa0sYmRiZS52y9Gpj3u 8Bg1vnBepfvEELYNt15ENTgIlqRQwoxKoPSd5uaW4+dDXbqYrS6H5ZWUpWYbHslV P+rB402YqFQfWdthl/3zYEM32bdWHZXBIOJTkBeQGn3d+AQdxCujSZ9agP1KumSr VJ9pvxaeU/CeKK+8h2b05O8+4RlOQP0oFlLp+99ywN9YojosdpKLL7ehFnywyGcT sHZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655442197; x=1655528597; bh=/BkAT2lwoDJl8DIX7TQ8zzeCIw4y ODjaLH6+Z35l4GY=; b=Km9v3bNldmyD9YljlCwwG9XKYOqvYKhYv9mkKWUTz5Yi VgXWQPbA0HCffa29GxChq1qiFLDJoDaQ8C96HbMRDxwoPvJ6ZkDswQ+NXR2XqfBv kVOOzv5OBujJNvDTwl5ofABF3sIEljWX3hNneUbrgrxFemBmrKR64Z1TvhE48wNf DvF9cVFdu0ZPVRfzCl8/UJuey58AdUnm3vDqZjQ284E8PlovTONsjssPLROIp3lG LbNBhJTMBfIjsCrHX7BLZuTs1aLPn+cFITs2WEyEedSzrluDc/mL5sAj1eARYQGZ +1krRXoFsoXxIouMphfEk80Ipyt4Iej/xzNfjh9F2A==
X-ME-Sender: <xms:FQusYhkO1d8w-4z6oAYxp4QGE3BpzCgGecF6FxORmcz8gfccb4Oi8w> <xme:FQusYs2SY61-N1OjST0I-RMv4wCC6OaGvzSuHnsuOj__GYEkri38tQbLn4YUw9EHT HVKWp240_g807ymBE0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvgedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeduleeufedthfegieeiieekkeejvdejgfevudffgeefvdffleev feekudeiieekleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:FQusYnoHplt4YiXR3GnOePw4e5vLnv5VoPHS-VX7P9SsEfwv6xzcmg> <xmx:FQusYhk3xCXCYHpodXGvzai0RA5MFdDnSTmji15OoZYMDbyFV5-aBg> <xmx:FQusYv2vWxNPkIxYoaDavAn_if2oHJ6p3OrwNSeXn5jiZOaWCDNMBg> <xmx:FQusYs_Z-vGbhrJBCrMUNLeFUiBWR8bESQs7jyN7nA9W5r7R5ckbnQ>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED1A82340083; Fri, 17 Jun 2022 01:03:16 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-712-gb9e94258b0-fm-20220610.001-gb9e94258
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <YqsBZ0M4lDXGRQTo@miskatonic> <> <> <> <> <>
Date: Fri, 17 Jun 2022 15:02:56 +1000
From: Martin Thomson <>
To: Willy Tarreau <>
Cc:, Amaury Denoyelle <>
Content-Type: text/plain
Received-SPF: pass client-ip=;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-6.8
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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: 1o248p-0002DA-FN 63d118c1f89260f1205fee3af759036d
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40142
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey Willy,

On Fri, Jun 17, 2022, at 14:53, Willy Tarreau wrote:
> Probably, but I'm still seeing it as a workaround. I mean, since HTTP/1.0
> we've been used to know when receiving a full headers block the entire
> list of the header fields. And it looks like with H3 the headers block
> is uncertain at the end of a HEADERS frame. 

I don't think that's right.  There are two layers at work here, but you do have a clear marker for the end of the header block.

The HEADERS frame has ended in this case, so you have a clear indication that you have all the headers.
The QUIC stream, which in this case hasn't ended, so you aren't sure if content or trailers might follow.

>    A sender which knows that no data follows the headers block SHOULD
>    signal the end of the message by setting the FIN bit along with the
>    HEADERS frame. A receiver that processes a HEADERS frame without
>    seeing a FIN bit MAY expect more data to follow regardless of the
>    HTTP method used.

This is entirely sensible advise to give, but it isn't always possible due to how different pieces of software work.  There are some rather fundamental design choices involved that can make it hard to guarantee that these two things leave at the same time.  As you say, most people can deliver on this, but not all.

> Sure but while you can often do this when you're a server, you practically
> can't when you're a gateway, because that would require to adjust the
> behavior per-URI. 

Yeah, a gateway is in a bad position here because they don't really speak for the resource and so - without extra information about resources, which could be made for all resources on a server, but probably won't be - they have to sit on their hands, buffer requests, and pay the ridiculous cost of doing that.

But if you take the fact that you have a clear signal that the headers are done, you can - even as a gateway - make some decisions.  It might not be 100% safe, but I can't see any origin servers complaining if you started processing from that point, for GET and HEAD requests at least.