net/http: don't require Host header for "PRI * HTTP/2.0" requests

[mtojek]

Hi,

I have been running two instances of simple HTTP server hidden behind HAProxy configured to terminate SSL and proxy further decrypted traffic.
Unfortunately, the implementation of http.Server connection handling processes HTTP/2.0 requests only when their TLS protos are manifestly defined (through TLSNextProto).
Now, proxying traffic through HAProxy (mode TCP) finishes with 400 Bad Request while PRI * HTTP/2.0 cannot be considered as valid Request-Line.

Best regards,
Marcin

[bradfitz]

There is already bug #14141 open ("x/net/http2: support h2c for http2"), but it sounds like you're speaking neither http2-over-TLS nor h2c.

@tamird did some work recently to support a very similar case. See grpc/grpc-go#555

BTW, PRI * HTTP/2.0 is a valid Request-Line. It's a 400 Bad Request because the lack of Host: ... line.

We should probably special-case the http2 client preface as not requiring a Host header, though.

I'll repurpose this bug for that.

[tamird]

FWIW, a nicer solution to this is possible with the use of cmux. See tamird/cockroach@a513df1#diff-4bf1ae5b9eb22814a15582886403053f for my implementation in CockroachDB where it's used to implement h2c.

The solution referred to in grpc/grpc-go#555 (manually spoofing the host header) is more trouble than it's worth, in my opinion.

[mtojek]

I agree with @tamird . Different way of handling HTTP requests in two versions of protocol should be solved by any strategy design pattern, even by multiplexing. I can only advise to consider websocket handling to be included in the multiplexing solution. req.expectsContinue() looks a bit weird...

[bradfitz]

I don't understand, @mtojek, do you no longer need this changed?

[mtojek]

@bradfitz
IMO this change is a must. I've just suggested to implement a solution (multiplexing) similar to suggested by @tamird . That's all.

[gopherbot]

CL https://golang.org/cl/21327 mentions this issue.