Code change:
From an interop discussion with NAME and NAME HTTP/1.1 the presence of a Host header: If no Host header is present, the section on 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 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 ). Do we want to have some guidance here? Or does this issue instead belong in URL to move some of the existing guidance to be HTTP version-independent? (NAME
NAME 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.
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.
":authority" exists for the purpose of always transporting the equivalent of the , 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?
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.
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.
Doesn't this beg the question "what if the request is for a URI that does not have a mandatory authority component?" All of the other cases are described. I would add something like: Thanks!

Related discussion:
text: All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT <del> request (connect).  An HTTP request that omits mandatory pseudo- header fields or contains invalid values for those fields is malformed (malformed). </del> <ins> request (connect). If the ":scheme" pseudo-header field identifies a scheme which has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header and "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those fields is malformed (malformed). </ins> HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.