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

Lucas Pardue <> Fri, 17 June 2022 10:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F0B6C15AAEF for <>; Fri, 17 Jun 2022 03:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Status: No, score=-2.759 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7PuWj1xzwDuW for <>; Fri, 17 Jun 2022 03:44:40 -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 D7D0FC15AAEE for <>; Fri, 17 Jun 2022 03:44:39 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o29QW-0006PY-HK for; Fri, 17 Jun 2022 10:42:08 +0000
Resent-Date: Fri, 17 Jun 2022 10:42:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o29QU-0006Of-SM for; Fri, 17 Jun 2022 10:42:06 +0000
Received: from ([2607:f8b0:4864:20::f36]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1o29QT-0005Oy-O7 for; Fri, 17 Jun 2022 10:42:06 +0000
Received: by with SMTP id q104so5812063qvq.8 for <>; Fri, 17 Jun 2022 03:42:05 -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=wvPxlcO93p8h6M2S0sQGylEEoS1BOtEiOpmdIjnUS/Q=; b=jcUGkG0KErE5XgbkUs2+DPwc44cBziSymbdfnd4xq9hcK5ykyvAQOe83OFO8YdEn0x 0cHt/0tx32IgkUuucCMF8r39gUiBFskioNRFJOb43QAgCy1QG5Rs/jNcqaeuZad0ay/T A7pgDZ9ji0xZFUy2AV710jg0uIvBjE2zKqHzf5Afdqf0qUdaFP1k4KEuu2fx0n9L/Ud1 n8Z0Qq7xiFmPox0ZIkRITTRMSEiI6OOVYhHFK73bfcz6jCCVacXJjCgeF8TQ2A0yfibd CQ273O8jiQLokqcGpY3Nrtfz7pmT/D45IbfcuCnAFTGUnH0JxW66dkwd6BuBL7cGl9Hx CiWQ==
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=wvPxlcO93p8h6M2S0sQGylEEoS1BOtEiOpmdIjnUS/Q=; b=d5OEaewTuIBSq/JZVGFaJvHmEeSWX8BBHo/8+waBQVTYk57Re/0HCB0ZG6+4eSriMQ Al8IWhlyW30HjM9mOlnutzrOxOuD/1fITvcbnpxntLuPOZpu+LqjUFI9OaW0Ik05N9hI MU5ZZx/p4vYoQU8rVKkVueP3QSYYOLgew8qcNepvWhymEB4nKKW4n5m09s/PvT696p83 DK9pKBn7PrLhjoXpxahJETA+WjuqBmEXEC+u50+aVQva52u9jgGkUU3KdWGOeX65funS M7H5BUQZl6vXBsH5y/YtGOVobBwQf9flDG+8GKH/ElOR1gbZvJawLNY4huWHR5KnhCkP oXnA==
X-Gm-Message-State: AJIora8f+8Mw9e9bjivPswG+eN9Hc+Wn8iOPZdRzzMBGReWnhEsugIB4 wiUt68VonJYEfo3P53G7v/9pSYN1UODdNSTqM2TZXC0z
X-Google-Smtp-Source: AGRyM1v4J9AQNg9xBjnZlAueoYE6otkfUELehQAV1j9YoqDv7jy6hArYIh5Fn11iEmj/6HfLrC5zvSlbiehBKSTFjww=
X-Received: by 2002:ac8:5bd4:0:b0:305:1f75:eca with SMTP id b20-20020ac85bd4000000b003051f750ecamr7617616qtb.23.1655462514723; Fri, 17 Jun 2022 03:41:54 -0700 (PDT)
MIME-Version: 1.0
References: <YqsBZ0M4lDXGRQTo@miskatonic> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Fri, 17 Jun 2022 11:41:43 +0100
Message-ID: <>
To: Willy Tarreau <>
Cc: Martin Thomson <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000021111c05e1a2679d"
Received-SPF: pass client-ip=2607:f8b0:4864:20::f36;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Scan-Sig: 1o29QT-0005Oy-O7 af7d13806a1eae49a7c54abc2b5547a5
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <>
X-Mailing-List: <> archive/latest/40153
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Some very interesting points here, can't respond to all of them due to time

On Fri, Jun 17, 2022 at 11:20 AM Willy Tarreau <> wrote:

> But given that we're still in the early days of such implementations, I'd
> rather see the pieces arrange correctly so that everything works as
> smoothly
> as it can. That's why if there's no strong objection against this, I'd file
> an errata to at least mention the issue and how to best deal with it from
> both sides, so that newcomers have a chance to notice it before they're
> engaged too deeply with their code.

The discussion illustrates there are several considerations around the
handling of translation between versions. Perhaps a lengthier piece of text
in an I-D that treats them all might be worth a consideration.

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.


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