W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Re: Host and :authority (was Re: Working Group Last Call: HTTP/2 revision)

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 7 Sep 2021 10:29:53 +0200
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
Message-ID: <20210907082953.GA29837@1wt.eu>
Hi Stefan,

On Tue, Sep 07, 2021 at 10:19:31AM +0200, Stefan Eissing wrote:
> > Sure, I definitely agree, it's just that the "must retain" rule maintains
> > the ambiguity regarding non-matching values.
> 
> Current Apache httpd h2 implementation:
> - if :authority: is given, it overrides host: before internal processing starts
> - if :authority: is missing, host: is used instead
> - if both are missing, request is rejected
 
That's what we currently do in haproxy as well.

> Proposal C would mean we check before overwrite and fail if a 'different'
> value is present. We then need to define 'different'. It seems quite common
> in the h1 world to be forgiving on port numbers, afaik. And how we match
> names...

Yep absolutely, that's the scheme-based URI normalization from RFC3986
IIRC that we're already applying to H1.

> After living for 5 years with the current implementation, I am not sure I'd
> like to change it.

I can understand, however, when working as a proxy, what do you pass to the
backend server ? I guess you're passing the only value you kept (i.e.
:authority when present), not two possibly different values ?

I'm OK with that (and that's what we're currently doing as well), but the
rule saying that Host must be preserved contradicts this as is suggests
the original one must be retained. I'm fine with retaining the header field
as a copy of :authority on output if it was present in order to address the
h2->h1->h2 case.

What I want to be certain of is that we do not make it possible for an
intermediary to pass mismatching host and :authority by default on output
and that the value emitted matches what was used internally.

Willy
Received on Tuesday, 7 September 2021 08:30:17 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 7 September 2021 08:30:18 UTC