Re: RFC 9113 and :authority header field

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Wed, 29 June 2022 09:24 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 C7386C15A750 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 29 Jun 2022 02:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.761
X-Spam-Level:
X-Spam-Status: No, score=-2.761 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_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 odr2SPHAwobs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 29 Jun 2022 02:24:27 -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 87A75C15A751 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 29 Jun 2022 02:24:27 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o6Tsv-00DQjZ-J7 for ietf-http-wg-dist@listhub.w3.org; Wed, 29 Jun 2022 09:21:21 +0000
Resent-Date: Wed, 29 Jun 2022 09:21:21 +0000
Resent-Message-Id: <E1o6Tsv-00DQjZ-J7@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tatsuhiro.t@gmail.com>) id 1o6Tsu-00DQiH-BT for ietf-http-wg@listhub.w3.org; Wed, 29 Jun 2022 09:21:19 +0000
Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <tatsuhiro.t@gmail.com>) id 1o6Tss-0075ZT-LI for ietf-http-wg@w3.org; Wed, 29 Jun 2022 09:21:19 +0000
Received: by mail-ej1-x631.google.com with SMTP id q6so31214128eji.13 for <ietf-http-wg@w3.org>; Wed, 29 Jun 2022 02:21:17 -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=8pIDuTFg/37SX/pckuEiHRuw13udlY0OASDKpT5OGiU=; b=MrhPelcPYqpr38n02USBgCsSBa47fgRtlr6AQ5cwlS3IehqfUVY4sp8WRvDt5vMvpQ gjsv9f8cYXnSCNpzdmwXFK2lrYBKNdVA635jeyb9hODvwj1qDZ24meBhzfSzLfUBRCUe 45LuxJVUQcKzzzCfCldMbxEetMU1YWsYrfkXyBn0J64o3JCfBLeOu/g/2KSR5ABJaRTZ yUNh4hMG8Kfpqk/W6kv5w13GXmsUbvh381dWQp6W8TqIu8RxwIZZCAST01MxNjOvN8KU aouPPGqPAeqajGuabDzyzKVp8awCG5c9Vta86IOjDcgIVH5GpWlVd+Ll2S10eykuavhD 2Wpw==
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=8pIDuTFg/37SX/pckuEiHRuw13udlY0OASDKpT5OGiU=; b=ofkypgSlwzPExxclNVvRD+1BJGZy/sH4Q4awOSV+HIhpxUya4PYiJ0UZzl2MVhwR2t D0WcDBBsCb8M7KjCy39OaBDay7XW+z6iun1T07mc/naY3PgOQjvirf3gmauh5TasvXhx yrLOIxrjNqKIPEzo/nkAV3ln9pjEO3I+0Q+AOYjZMujJrCmE/6B6I6AojO10wkT6SRdY 2AxLK+KM1AsH4Q7bTz796A1Lg6BOafp6Hfc8jff7fP4JnKVEsEI6yG/Bm0sPDD0yF+Qh 1UFdU7J025frZ3/HlQp3sWvofSWABbUCKCPD9HEumgE9wero95j/W05gjCGfXgSx7HaF e9kA==
X-Gm-Message-State: AJIora+pNaLgNnQOh2ShB1X94AKw9tB9xhr/+wobiiwqgy2jdKHVCrJt 0b41LyKOwJYYDIC0VX4kWeOO++JrobKHGRdmLCZsKSZe
X-Google-Smtp-Source: AGRyM1s6NTCIF4V2Ue2tflIfULII1j4yONOhxhLAfaAaY9atcSChFnnJxHJBi1/FRudO6yY0EE6eW3Du3PeW8t0rZTM=
X-Received: by 2002:a17:907:6d81:b0:711:e5f9:91b8 with SMTP id sb1-20020a1709076d8100b00711e5f991b8mr2275520ejc.125.1656494465955; Wed, 29 Jun 2022 02:21:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAPyZ6=+q+MoOOwoCxbtFjt+gqsjHBqTzz9KXNVcs3EP-4VFp=Q@mail.gmail.com> <D7142A8A-5B80-46F5-A653-2307EE2DC5D8@gbiv.com> <CAPyZ6=LCSDAsPoFCQ2cRO-i+dpo5vnp2L5A7ZLw8dvRtDs6HUg@mail.gmail.com> <20220629055254.GA18881@1wt.eu>
In-Reply-To: <20220629055254.GA18881@1wt.eu>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 29 Jun 2022 18:20:54 +0900
Message-ID: <CAPyZ6=Kt3rb_qcM9AzvUfj2wSQNmqNo3rOPiCQFbFAyT7sbdeg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: HTTP <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000373a4d05e292acb1"
Received-SPF: pass client-ip=2a00:1450:4864:20::631; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ej1-x631.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=tatsuhiro.t@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.1
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_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_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1o6Tss-0075ZT-LI e111da2ac0a32b70fc40df658c17eb7c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RFC 9113 and :authority header field
Archived-At: <https://www.w3.org/mid/CAPyZ6=Kt3rb_qcM9AzvUfj2wSQNmqNo3rOPiCQFbFAyT7sbdeg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40219
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 Wed, Jun 29, 2022 at 2:52 PM Willy Tarreau <w@1wt.eu> wrote:

> Hi Tatsuhiro,
>
> On Wed, Jun 29, 2022 at 08:58:47AM +0900, Tatsuhiro Tsujikawa wrote:
> > RFC 7540 even says that :intermediary MUST omit :authority "when
> translating
> > from an HTTP/1.1 request that has a request target in
> > origin or asterisk form (see [RFC7230], Section 5.3)."
> >
> > Now RFC 9113 has this text:
> >
> >       An intermediary that forwards a request over HTTP/2 MUST construct
> >       an ":authority" pseudo-header field using the authority
> >       information from the control data of the original request, unless
> >       the original request's target URI does not contain authority
> >       information (in which case it MUST NOT generate ":authority").
> >       Note that the Host header field is not the sole source of this
> >       information; see Section 7.2 of [HTTP].
> >
> > This means :authority must be included if the host header field exists in
> > an HTTP/1.1 request.
>
> My understanding is that Host doesn't necessarily count as "control data"
> here, and that the goal was to accurately represent an HTTP/1.x request
> targetting an HTTP/1.0 server after being transported over HTTP/2. For
> example, let's say that a client passes this to a proxy:
>
>      GET http://example.com/ HTTP/1.0
>      Proxy-connection: keep-alive
>
> and nothing more. If instead it gets sent via a gateway that transports
> it over H2, it could make sense to consider that the scheme is "http",
> the authority is "example.com", that there's no host, hence the request
> would be passed as:
>
>      :method: GET
>      :scheme: http
>      :authority: example.com
>
> and that's all. Conversely, let's see the same HTTP/1.0 request sent
> directly to the origin server:
>
>      GET / HTTP/1.0
>
> There's no more authority nor host, so a gateway receiving that cannot
> invent one, unless it uses its own configured name corresponding to its
> own address, that it expects the client used to construct the request.
>
> With HTTP/1.1 there are less ambiguities since Host is mandatory, but
> the distinction between "proxy requests" and origin requests is still
> relevant, especially when you don't know whether or not the origin
> server supports HTTP/1.1 or only 1.0 (and may be confused by the
> presence of an authority in the request line). For example, if a
> client sends:
>
>   GET / HTTP/1.1
>   Host: example.com
>
> to an HTTP/1.0 server that parses Host, it will work. If it sends
>
>   GET http://example.com/ HTTP/1.1
>   Host: example.com
>
> To an HTTP/1.1 server, it will work as well, but it may fail to an HTTP/1.0
> server (or worse, loop over itself if it supports proxing requests and
> resolves itself as example.com).
>
> If the first request is transported over H2, thus converted from H1 to
> H2 then back from H2 to H1, adding an authority that was not initially
> present would introduce exactly this problem. By not adding it and using
> Host only, the request representation is preserved, and the origin server
> can receive the same request that the client took care to encode, and not
> be confused. That's why I'm saying that in this case it's clearly visible
> that Host isn't part of the "control data" and must not appear in an
> authority that was not initially encoded.
>
> I know it's a bit complicated but we have to deal with history. What we're
> doing in haproxy is that both Host and :authority are used interchangeably
> after having been checked for proper matching, and are modified at the
> same time if needed, and we have a flag indicating if an authority was
> present in the incoming request to know if we have to produce one on
> output or not. That's in the end what seems to preserve the most accurate
> representation along a chain of multiple versions. This allows us to emit
> a Host field only if one was present, and an authority only if one was
> present, regardless of the HTTP version. I don't think that RFC9113 brings
> any changes regarding this, it might only be a matter of what constitutes
> "control data".
>
>
Thank you for the explanation.
I reread the relevant section of RFC 9113, and you are right that it has
not changed on this.

Best,

Tatsuhiro Tsujikawa


> Hoping this helps,
> Willy
>