Is absence of both :authority and Host an error?

[MikeBishop]

From an interop discussion with @martinduke and @kazuho.

HTTP/1.1 requires the presence of a Host header:

A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.5.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value.

If no Host header is present, the section on Effective Request URI describes how you determine what host is being asked for, ending with "guess" if it's an HTTP/1.0 request.

HTTP/2 says that you generate an :authority pseudo-header if sending direct-to-H2 and carry through the Host header if you're relaying HTTP/1.1. There is no discussion about what to do with an HTTP/1.0 (or 0.9) request being relayed over HTTP/2, which wouldn't have a Host header; you're neither required to generate or send one, even an empty one, nor are you given guidance about how to figure it out.

HTTP/3 carries forward the H2 language (currently by reference, and explicitly after #3352). Do we want to have some guidance here? Or does this issue instead belong in https://httpwg.org/http-core/ to move some of the existing guidance to be HTTP version-independent?

(@royfielding)

[kazuho]

@MikeBishop Thank you for looking into the problem.

Regarding if (or how) we should handle the issue, I think my weak preference goes to having one rule that applies to both HTTP/2 and HTTP/3. That would be less surprising to the users, and would also be helpful to implementations. It could well be the case for an HTTP server to have a common logic of handing pseudo headers (or lack of) between HTTP/2 and HTTP/3.

[royfielding]

Host is an HTTP/1.x header field (it was just late to the party), so HTTP/1.0 includes it as an extension. And that requirement is specific to HTTP/1.1, so would theoretically not apply to HTTP/1.2 (and that was intended): it was a short term requirement imposed by the IESG because they wanted to require deployment and didn't understand that it was already deployed.

In general, I don't understand why ":authority" exists (as opposed to always using ":host"), but I think the HTTP requirement is simply that the identifying data must be present somewhere in the request.

[MikeBishop]

":authority" exists for the purpose of always transporting the equivalent of the absolute-form, with ":scheme" and ":path" transporting the rest. It's mostly a consistency thing, I think. If you have a "Host" header instead, that's acceptable, too.

So should we say that the target authority MUST be present in either "Host" or ":authority", or do we leave it alone?

[royfielding]

Well, assuming we still allow requests for URIs that do not have an authority component (e.g, a URN or similar), I think it is better to just leave it alone. OTOH, folks are still going to ask what needs to be sent when the request target doesn't have an authority component, so that ought to be defined somewhere here more sensibly than it was for 1.1.

[larseggert]

Discussed in ZRH. Proposed resolution is that if a URI scheme has a mandatory component, it better have one of those two things, preferably a :authority. Alert httpbis.