Re: RFC 9113 and :authority header field

[Willy Tarreau <[e-mail]>]

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