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

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 16 June 2022 22:29 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 DF9E5C15AACA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 15:29: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=unavailable 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 bQ6HHcddi6u0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 15:29:49 -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 29B73C14CF18 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Jun 2022 15:29:48 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o1xwP-000610-GV for ietf-http-wg-dist@listhub.w3.org; Thu, 16 Jun 2022 22:26:17 +0000
Resent-Date: Thu, 16 Jun 2022 22:26:17 +0000
Resent-Message-Id: <E1o1xwP-000610-GV@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) 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 1o1xwN-0005zn-Ck for ietf-http-wg@listhub.w3.org; Thu, 16 Jun 2022 22:26:15 +0000
Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1o1xwK-00088e-Mi for ietf-http-wg@w3.org; Thu, 16 Jun 2022 22:26:15 +0000
Received: by mail-qv1-xf2e.google.com with SMTP id u8so4153009qvj.2 for <ietf-http-wg@w3.org>; Thu, 16 Jun 2022 15:26:12 -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=vpDcr24nEBTflzAT1uxfn2HipFbzGzY8mXbW413TVHI=; b=Dm6Co/rifOFtz/sN4wpgteJSIGkacji+f3DQSicbFdjk7rturk0JFVTQkVIC+htL8R qgcrkN6rtlk5JQqlhmoKBdbsN15dQTa2fbkDKVaRsHidDX9rnsiSgnAkZ2RrigLwE14e 1ACV0djXphpTlnQXLcNCSAg+prJeyHXj9txV++WbN0YR0/qv0QUyep7BY5H573OiOv2o 7EnRiowoyobUkc4kotwhLOAXnSqg8HazZf77qiX0BTzP7yY2R7h14Lk5+K84aMZNdcyB pXFS6WhRyHJzynAjYfG0K1C9+SvNHwSyZjl+Z+6weN6n5KZ+vG0Fa3hZHgrFDIoqUclV Dz/w==
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=vpDcr24nEBTflzAT1uxfn2HipFbzGzY8mXbW413TVHI=; b=xxbCA51aYQuVDaVVw8CzsGWXgTUkoOpIzPgSJRCKlYgfLIO+773ooSupgKcZEg5m8F 5+PzVLRigNpZP/0SP2I5h+bUgWNjp0wEvRVGQYCBiP7poV2oQmwLuCCc+8SYkYbILnGx AruWYQTylnBcnekSp5I9O16niP2/MaXIgTmAtzwAyS30bs1Bpkkj4caJu8ZUnIEdwkyh 1DYX05XL3ekPYOIjkGxdTvOvW0O4vNOq1unL9Z6CNpvkrtomLRlkAtbt6YYazDmBCiJs qOhXbPC4lKsUH4oNQDP6JIrp86RM+feKk0jTF4jyA2vkklqowmKwDVSXd3ABkyIJoUIt 9Pow==
X-Gm-Message-State: AJIora8FYtl/U2BNBk3JVerHD8/A2NjiuNXnG+weBqKuiZPQseKQ9ziE be7FHZAWI7irUu/NTqs0WW7aNmpLXYxD0g2Yn2JHxv4Q
X-Google-Smtp-Source: AGRyM1tw4a9Vo4leA+oRwkhhySQol9dTmmHIF1amHrW62SNsJ55Wia0N+Dq3epQcajt6KzyeFjH9TkYH/CjsPTn0elg=
X-Received: by 2002:ad4:5bae:0:b0:46b:8c02:5dbc with SMTP id 14-20020ad45bae000000b0046b8c025dbcmr6201987qvq.94.1655418360804; Thu, 16 Jun 2022 15:26:00 -0700 (PDT)
MIME-Version: 1.0
References: <YqsBZ0M4lDXGRQTo@miskatonic> <CAJ_4DfRD9ktc1cmDd8GmQDx8iX6s=NYj3C9MW-3-yU+SZYxkEQ@mail.gmail.com>
In-Reply-To: <CAJ_4DfRD9ktc1cmDd8GmQDx8iX6s=NYj3C9MW-3-yU+SZYxkEQ@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 16 Jun 2022 23:25:48 +0100
Message-ID: <CALGR9obvYB-2vYXYgwSMpS3s8uSbLKn0ZF39piYQ_ROt8DAXJg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Amaury Denoyelle <adenoyelle@haproxy.com>, IETF QUIC WG <quic@ietf.org>, Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059b82505e1981f85"
Received-SPF: pass client-ip=2607:f8b0:4864:20::f2e; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-qv1-xf2e.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: mimas.w3.org 1o1xwK-00088e-Mi 234ccbb001888e529251872e3565ee29
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/CALGR9obvYB-2vYXYgwSMpS3s8uSbLKn0ZF39piYQ_ROt8DAXJg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40134
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>

Hi Amaury,

+ the HTTP WG list, since they now own HTTP/3 and in case there are folks
over there not watching QUIC closely.


On Thu, Jun 16, 2022 at 11:23 PM Ryan Hamilton <rch=
40google.com@dmarc.ietf.org> wrote:

> Instead of assuming chunked encoding in this case, an intermediary could
> delay sending the request until it either receives the QUIC FIN, or
> receives an HTTP/3 DATA frame, right? (Though admittedly, that is a
> potentially performance hit). Now that HTTP/3 is RFC 9114, I suspect it's
> too late to add new normative language.
>
> Cheers,
>
> Ryan
>
> On Thu, Jun 16, 2022 at 3:08 PM Amaury Denoyelle <adenoyelle@haproxy.com>
> wrote:
>
>> Hello,
>>
>> I have read HTTP/3 specification and I do not find any requirement on
>> setting the FIN bit of a QUIC STREAM frame which contains a H3 HEADERS
>> if the request does not have a body.
>>
>> For me, it represents an ambiguity on the internal HTTP message
>> representation. If no content-length header is present, it could be
>> interpreted as equivalent to HTTP/1.1 chunked transfer encoding. This
>> ambiguity could be removed by requiring the STREAM FIN bit set for the
>> frame containing H3 HEADERS if no body is present. If instead it's
>> preferable to maintain a separation between HTTP/3 and QUIC, maybe a new
>> H3 internal mechanism could be implemented to signal the end of a stream
>> without a body.
>>
>> I think this issue is particularly important for intermediaries, such as
>> haproxy. Currently, when receiving a H3 HEADERS frame from a client
>> without the underlying STREAM FIN bit set, we generate for the server a
>> HTTP/1.1 message with a chunked transfer encoding body. This is to
>> ensure that we do not discard any possible arriving H3 DATA frames
>> after. However, a lot of HTTP servers are stricter with the presence of
>> a body and will for example reject GET requests with a chunked transfer
>> encoding.
>>
>> Please let me know your thoughts on the subject,
>> Regards,
>>
>> --
>> Amaury Denoyelle
>>
>>