Subject: [quicwg/base-drafts] Is absence of both :authority and Host an error? (#3408)

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Feb 2020 02:58:35 -0800

>From an interop discussion with @martinduke and @kazuho.

HTTP/1.1 [requires](https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.host) 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](https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html#h1.effective.request.uri) describes how you determine what host is being asked for, ending with "heuristics" 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 #3407).  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)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Feb 2020 03:09:04 -0800

@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 for 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408#issuecomment-581857746

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 04 Feb 2020 03:12:43 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408#issuecomment-581859113

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Feb 2020 04:58:25 -0800

":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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408#issuecomment-581897956

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 04 Feb 2020 05:27:49 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408#issuecomment-581909000

---

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 07:26:15 -0800

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. Punt to httpbis.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3408#issuecomment-582461114