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

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 17 June 2022 17:44 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1906C157B34 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jun 2022 10:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Level:
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQLuObpLSqtu for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jun 2022 10:44:44 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 9979FC14792A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Jun 2022 10:44:43 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o2Fz9-0004jH-BM for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Jun 2022 17:42:19 +0000
Resent-Date: Fri, 17 Jun 2022 17:42:19 +0000
Resent-Message-Id: <E1o2Fz9-0004jH-BM@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1o2Fz8-0004iO-Ai for ietf-http-wg@listhub.w3.org; Fri, 17 Jun 2022 17:42:18 +0000
Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1o2Fz7-0005Oj-0o for ietf-http-wg@w3.org; Fri, 17 Jun 2022 17:42:18 +0000
Received: by mail-qk1-x731.google.com with SMTP id c83so3654088qke.3 for <ietf-http-wg@w3.org>; Fri, 17 Jun 2022 10:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODdn9gs2RBjESJzAtVIQzpe+0l8n4HyhgjzdAf7Bbkk=; b=X1NIQqO45JFU75F2N85hOBFAUH5/MFMtVXDi/ZM9I8BFRqQUR3LEm+aYILUB57in+m 6XREFrnv2y8SCNcPkrnDZG/3bx7PWzaoa4DxpHpCQP+s1eLCHGSc++W8aoBbpcA8CwdH rUOO2CQ446AUz1EJk/JtZBZHe8TrFHrnHkq9r6MmDMezE5SzR5e9C62dHUsxc6wyBMcS 1onwatVO2HcApLIDeKlAkkeUGNGex5o3CKcWEQMXZMtRvZjwKjpu7OJbiIwWQsE25ksz Dhz7pe1FC5s9k+4Xt2XChTbFcsbfDF4b/LXF5weyBZkWrbRPbGODDEUV3Isxe5uuZhdR /7ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODdn9gs2RBjESJzAtVIQzpe+0l8n4HyhgjzdAf7Bbkk=; b=LT5QPTgbCp3OmIgCVxrfU1YJRq+cH/TnNO5z1v1XlmfNFVUuON6QD/I/DZ6DPD7cEg 5eccyEQmG59AVHsFtfwgrDJkS0Ma9ZHhtAULQL4d/4S3E8LW1B0TjM6P6siN9RhVQATB 3YrmTpSNdRwMglpR59NatfJUDH5EsARMUsUSBY3T0MERAuyjhjiGgxVqs5XCoDDCxgvy kAT4uN7aKjcJ4AIGEHRlAnn4YUP390DUo7F/OEchqSjYOZAmBBK2Ypdrj6wyQ27sIbgc 4xgUOYTq+NxyjnYebC/vLn3nnOIGXT03YXGjl2pt0hZLWLrPTtRI9U2tQpIxQ8WQElB8 1rYw==
X-Gm-Message-State: AJIora8tFCOnhW/UzkURr4E8WqKteaWnH5EZ1Av0MAUly61K2v2QenLt X0fm5rvn6c1D8mmvziSksGTMHcFjUyN+u54WT6w=
X-Google-Smtp-Source: AGRyM1tOOZwqFFcEdhu3QeDyrsGXyRjMvJB3NzN9A8aHH+vJpBsgeLiG8NOwS/U1YobY/yw0LIjBA215yVwgRxSCnrI=
X-Received: by 2002:a05:620a:198b:b0:6a6:cdec:d5cf with SMTP id bm11-20020a05620a198b00b006a6cdecd5cfmr7809992qkb.71.1655487726107; Fri, 17 Jun 2022 10:42:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ_4DfRD9ktc1cmDd8GmQDx8iX6s=NYj3C9MW-3-yU+SZYxkEQ@mail.gmail.com> <CALGR9obvYB-2vYXYgwSMpS3s8uSbLKn0ZF39piYQ_ROt8DAXJg@mail.gmail.com> <CAPDSy+5-+L_F8gOYht2OWmWHnp4JtWt4tfPbM_TN799AgK7H1A@mail.gmail.com> <71b309c9-0220-4e14-8be5-13f2cb1d1278@beta.fastmail.com> <20220617045330.GB30314@1wt.eu> <d2a71dca-1c0d-416e-8f94-700114266aaf@beta.fastmail.com> <20220617053700.GD30314@1wt.eu> <b5e21b22-e447-4ba1-b907-e2785deb2d5d@beta.fastmail.com> <20220617101722.GA30560@1wt.eu> <CALGR9oba=7Ajf2p+hf+yNVGiaQ1=Vwarq5iPxCmUxLMT_7m0AQ@mail.gmail.com> <20220617104853.GA30707@1wt.eu> <CAPDSy+59E4MJ+OkEEEUN_XykEg8qy7AQPTUs5J0XuKOhomCXLQ@mail.gmail.com>
In-Reply-To: <CAPDSy+59E4MJ+OkEEEUN_XykEg8qy7AQPTUs5J0XuKOhomCXLQ@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 17 Jun 2022 18:41:56 +0100
Message-ID: <CALGR9oamxk90KX6EttXRTG00PynPXnhiki_59ro6e-Y45EDPoA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000d843f705e1a84595"
Received-SPF: pass client-ip=2607:f8b0:4864:20::731; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-qk1-x731.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=lucaspardue.24.7@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.9
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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: titan.w3.org 1o2Fz7-0005Oj-0o c9958774c763f3abb01b05a35eabe5f7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Ambiguity on HTTP/3 HEADERS and QUIC STREAM FIN requirement
Archived-At: <https://www.w3.org/mid/CALGR9oamxk90KX6EttXRTG00PynPXnhiki_59ro6e-Y45EDPoA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40156
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, 17 Jun 2022, 18:31 David Schinazi, <dschinazi.ietf@gmail.com> wrote:

> Since it's Friday and we're exploring crazy thoughts, instead of
> ":no-content" why not simply content-length=0?
> David
>

My thinking is that for an H2-to-H2, H3-to-H3 gateway (or some variant),
that  the content-length is optional and explicit declaration of chunked
T-E cannot be relied upon to guess if there's content coming. So a
pseudo-header fills the gap between ndicating an end to request after the
current flight, without having to wait for ES or FIN. Pseudo-headers are
also a property of the frame, so don't risk affecting the end-to-end
message semantic.



> On Fri, Jun 17, 2022 at 3:49 AM Willy Tarreau <w@1wt.eu> wrote:
>
>> 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 ;-)
>>
>> Willy
>>
>>