Re: RFC 9113 and :authority header field
Willy Tarreau <w@1wt.eu> Wed, 29 June 2022 05:56 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 91D90C13CD9A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 22:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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
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 PLdTP4lnOBxp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 22:56:42 -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 B6A59C15CF3B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 Jun 2022 22:56:42 -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 1o6QdR-00CsWw-Cg for ietf-http-wg-dist@listhub.w3.org; Wed, 29 Jun 2022 05:53:09 +0000
Resent-Date: Wed, 29 Jun 2022 05:53:09 +0000
Resent-Message-Id: <E1o6QdR-00CsWw-Cg@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 <w@1wt.eu>) id 1o6QdQ-00CsW3-ES for ietf-http-wg@listhub.w3.org; Wed, 29 Jun 2022 05:53:07 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.94.2) (envelope-from <w@1wt.eu>) id 1o6QdO-0070Kj-IB for ietf-http-wg@w3.org; Wed, 29 Jun 2022 05:53:07 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 25T5qshA018903; Wed, 29 Jun 2022 07:52:54 +0200
Date: Wed, 29 Jun 2022 07:52:54 +0200
From: Willy Tarreau <w@1wt.eu>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: HTTP <ietf-http-wg@w3.org>
Message-ID: <20220629055254.GA18881@1wt.eu>
References: <CAPyZ6=+q+MoOOwoCxbtFjt+gqsjHBqTzz9KXNVcs3EP-4VFp=Q@mail.gmail.com> <D7142A8A-5B80-46F5-A653-2307EE2DC5D8@gbiv.com> <CAPyZ6=LCSDAsPoFCQ2cRO-i+dpo5vnp2L5A7ZLw8dvRtDs6HUg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPyZ6=LCSDAsPoFCQ2cRO-i+dpo5vnp2L5A7ZLw8dvRtDs6HUg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-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 1o6QdO-0070Kj-IB b726c90db8015c50e9cb09ef831f2b2d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RFC 9113 and :authority header field
Archived-At: <https://www.w3.org/mid/20220629055254.GA18881@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40216
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 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". Hoping this helps, Willy
- RFC 9113 and :authority header field Tatsuhiro Tsujikawa
- Re: RFC 9113 and :authority header field Roy T. Fielding
- Re: RFC 9113 and :authority header field Tatsuhiro Tsujikawa
- Re: RFC 9113 and :authority header field Martin Thomson
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field Tatsuhiro Tsujikawa
- Re: RFC 9113 and :authority header field Stefan Eissing
- Re: RFC 9113 and :authority header field Tatsuhiro Tsujikawa
- Re: RFC 9113 and :authority header field Roy T. Fielding
- Re: RFC 9113 and :authority header field David Schinazi
- Re: RFC 9113 and :authority header field Martin Thomson
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field Stefan Eissing
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field Roy T. Fielding
- Re: RFC 9113 and :authority header field Willy Tarreau
- Re: RFC 9113 and :authority header field David Schinazi
- Re: RFC 9113 and :authority header field Kazuho Oku
- Re: RFC 9113 and :authority header field Kazuho Oku
- Re: RFC 9113 and :authority header field Willy Tarreau