nginx returns 400 beacuse of missing host header when receiving HTTP2 :authory pseudo field

[https://stackoverflow.com/users/795910/ottavio-campana]

I have a client that connects to the webserver. After sending the magic to upgrade to HTTP2, I have an exchange of settings and one request is POSTed to the server.

Nignx returns 400 and by checking in the error file; I find this

client sent invalid host header while reading client request headers, client: 127.0.0.1, server: localhost, host: ""

It's true, the Host: header is missing. But this is no longer an HTTP/1.1 session, it is an upgraded HTTP/2 connection now. The client sends in the SETTINGS packet the :authority pseudo-field.

In section §8.1.2.3 of ​https://tools.ietf.org/html/rfc7540 it is written

Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field.

Therefore I think that in this case Nginx should:

• check that :authority is present
• recognize as valid the empty :authory pseudo-field according to RFC3986
• not give an error because the Host: header is missing.

[Maxim Dounin]

For missing header, nginx will log that client sent HTTP/1.1 request without "Host" header instead. The error quoted is about _invalid_ host header, not missing one. The message itself prefers the HTTP/1.1 name as it is more generic one, yet it is actually used for both Host and :authority.

Both Host and :authority headers cannot be empty. In particular, the :authority header is ​defined as follows:

   o  The ":authority" pseudo-header field includes the authority
      portion of the target URI ([RFC3986], Section 3.2).  The authority
      MUST NOT include the deprecated "userinfo" subcomponent for "http"
      or "https" schemed URIs.

In RFC 3986 the authority portion is ​defined as:

      authority   = [ userinfo "@" ] host [ ":" port ]
      host        = IP-literal / IPv4address / reg-name
      reg-name    = *( unreserved / pct-encoded / sub-delims )

The reg-name can be empty only if specifically premitted by the URI scheme:

   If the URI scheme defines a default for host, then that default
   applies when the host subcomponent is undefined or when the
   registered name is empty (zero length).  For example, the "file" URI
   scheme is defined so that no authority, an empty host, and
   "localhost" all mean the end-user's machine, whereas the "http"
   scheme considers a missing authority or empty host invalid.

As explicitly stated in the above quote from RFC 3986, the "http" scheme does not permit empty reg-name. Normative text is in ​RFC 7230:

   A sender MUST NOT generate an "http" URI with an empty host
   identifier.  A recipient that processes such a URI reference MUST
   reject it as invalid.

Summing the above: if your client uses an empty :authority header, you have to fix your client.

[https://stackoverflow.com/users/795910/ottavio-campana]

Excuse me if I am pedantic, but I am not 100% sure that your explaination is correct.

RFP3986 states:

whereas the "http" scheme considers a missing authority or empty host invalid.

For my understanding, this sentence covers two cases:

• the case of HTTP/1.1, where empty Host: is invalid
• the case of HTTP/2, where the missing :authority is invalid

But, a missing :authority field is different from a present-but-empty pseudo-field.

Furthermore, RFC7230 is about HTTP/1.1, not about HTTP/2. The client I am using supports only HTTP/2, it will never send an HTTP/1.1 request.

So, I follow your explanation, I agree on most of it, but I think that you are not interpreting correctly missing :authority as empty :authority . I see no support in the RFCs you quoted about the equivalence missing == empty.

[Maxim Dounin]

RFC 3986 talks about syntax components authority and host, not about headers or pseudo headers. And the wording is pretty clear.

Moreover, ​RFC 7540, which is about HTTP/2, is pretty clear that RFC 7230 is what defines "http" and "https" URI schemes for both HTTP/1.x and HTTP/2.

   Selected portions of HTTP/1.1 Message Syntax
   and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
   also applicable in HTTP/2, but the expression of those semantics for
   this protocol are defined in the sections below.

If you are still not 100% sure, I can't help, sorry.

[https://stackoverflow.com/users/795910/ottavio-campana]

Ok, thank you for your feedback.

It's correct to close the bug as invalid.