W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: RFC 9113 and :authority header field

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 30 Jun 2022 10:32:35 -0700
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, HTTP <ietf-http-wg@w3.org>
Message-Id: <1233090A-E62F-4D4F-8F9B-1F14785386A8@gbiv.com>
To: Willy Tarreau <w@1wt.eu>
> On Jun 30, 2022, at 2:02 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Jun 30, 2022 at 09:01:23AM +0200, Willy Tarreau wrote:
>>>> 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".
>>> Sorry, that is a broken implementation. You need to send Host regardless
>>> of the original request version.
>> I can guarantee you that each time we accidently failed to do this because
>> of a tiny change or some strengthening of the checks of host vs authority,
>> we got instant reports of various 1.0 applications getting broken. And
>> actually I did verify carefully that the updated set of RFCs continued to
>> cover that compatibility requirement with these old components, i.e. Host
>> remains Host and :authority remains :authority along all the chain, and
>> only when both are set, they must match and we can simplify (e.g. drop
>> authority when passing to an HTTP/1.x server).
> BTW, I think I just understood the case that concerned you and I was
> partially incorrect above, as we do *always* create a Host header on
> output since it's obviously always valid, we only make the difference
> on the authority to decide whether to rebuild and absolute or origin
> form for the URI.
> Sorry for this confusion.
> Willy

Heh, no worries ... I was wondering how it could possibly work, unless
you happened to be testing on single-origin default servers. It makes me
wonder what happens when a hostless request hits a CDN -- I haven't
even tested that in ages.


Received on Thursday, 30 June 2022 17:32:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC