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

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

From: Martin Thomson <mt@lowentropy.net>
Date: Mon, 06 Sep 2021 15:20:54 +1000
Message-Id: <4ef4d3bf-c587-428d-b413-ef1199bd9ca4@www.fastmail.com>
To: ietf-http-wg@w3.org
On Fri, Sep 3, 2021, at 15:55, Willy Tarreau wrote:
> > and have both h1 requests look the same by preserving Host instead
> > of :authority. Is that right? Maybe the spec should explain it.
> I'm fine with clarifying something for this. We already support various
> combinations of host/authority in haproxy in order to preserve as much
> as possible the origin vs absolute form for H1, with the exception that
> H2->H1 always switches to origin form due to the ambiguity in H2 that
> doesn't provide the distinction between the two forms. But it could be
> stated that:
>   - origin forms have either authority or host
>   - absolute forms have both

In effect, RFC 7540 says:

1. If :authority is present, servers must use :authority and ignore Host.
2. Servers use Host if :authority is absent.
3. Intermediaries must preserve Host when forwarding requests.
4. Clients are encouraged to generate requests with :authority, but can use Host if they choose.

Roy's theory about h2->h1->h2 being the reason for (3) is correct, at least as far as I can remember (something I've confirmed with others who were there).  My *opinion* is that this is a poor design for a few reasons, but mostly because Host and :authority can disagree.

Is this really so bad that it needs to be fixed?

I've seen a few amendments suggested in this thread (and others):

a. We might make :authority mandatory in more cases.
b. We might prohibit inclusion of both values.
c. We might prohibit different values if the fields are both present.
d. We might avoid levying requirements on intermediaries that forward requests.

We are limited in what we can do here because we can't require anything that might result in an unmodified RFC 7540 implementation producing fatal errors.  For instance, we might insist that clients not include both fields, but we can't require servers to enforce that.  That limits the value of any change.

The best option I've seen for any change is to remove the bit where we mandate that Host is preserved when forwarding.  We might further recommend against including Host in favour of :authority.  That's in direct contradiction to decisions in RFC 7540, but I think we have some support for the notion that we made a mistake in mandating that Host be preserved.

Doing nothing is also OK.  It is a invalid to route on Host when :authority exists; that some implementations might do that is not something we are obligated to fix in the specification.  Were this a new protocol, with fewer constraints that might affect interoperability, choosing the safest option would be best, but we're talking about a very narrow update.

This sort of issue is exactly the sort of thing that our initial scoping exercise was designed to avoid.  There are lots of decisions in RFC 7540 that we might second guess; we deliberately chose not to redo all of them.  And yet here we are.


p.s., the editor's draft contains a revision to the text in question, that I think greatly improves its clarity; see https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#section-8.3.1-2.3.1
Received on Monday, 6 September 2021 05:21:29 UTC

This archive was generated by hypermail 2.4.0 : Monday, 6 September 2021 05:21:35 UTC