Draft: draft-ietf-quic-http

Commentary: From an interop discussion with and 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 would n'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 to move some of the existing guidance to be HTTP version - independent ? ( 
 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 . 
  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 did n't understand that it was already deployed . In general , I do n'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 does n'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 . 
 Does n'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 !
Paragraph (version A):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (connect).  An HTTP request that omits mandatory pseudo-
header fields or contains invalid values for those fields is
malformed (malformed).
Paragraph (version B):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (connect).
Paragraph (version B):
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.
Paragraph (version B):
An HTTP request that omits mandatory pseudo-header fields or contains
invalid values for those fields is malformed (malformed).