Boulder: VA: Return meaningful error message when HTTP-01 connects to an HTTP/2 server

[cpu]

Presently when an HTTP-01 challenge request from the VA encounters an HTTP/2 server on port 80 (a misconfiguration, but one that happens in the real world) the generic problem:
{"type":"connection","detail":"Fetching http:/example.com/.well-known/acme-challenge/XXXXXX: Error getting validation data","status":400} is returned to the user.

The VA itself logs the true cause:

 Err:(*errors.errorString)(0xc420609bf0)}] errStr=[Get http://example.com/.well-known/acme-challenge/xxxxxxx: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x12\x04\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x80\x00\x04\x00\x01\x00\x00\x00\x05\x00\xff\xff\xff\x00\x00\x04\b\x00\x00\x00\x00\x00\u007f\xff\x00\x00\x00\x00\b\a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01"]

We should handle this similar to a server misconfigured to speak HTTP on port 443 and return a better error message when we can match the HTTP/2 bytes in the malformed response.

[mnordhoff]

Example of an HTTP/2 response from yesterday:

00000000  00 00 12 04 00 00 00 00  00 00 03 00 00 00 80 00  |................|
00000010  04 00 01 00 00 00 05 00  ff ff ff 00 00 04 08 00  |................|
00000020  00 00 00 00 7f ff 00 00  00 00 08 07 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  01                       |.........|
00000039

https://tools.ietf.org/html/rfc7540#section-4.1
https://tools.ietf.org/html/rfc7540#section-6.5

I only partly understand that, but it could make sense to match the header "00 00 xx 04 00 00 00 00 00" (initial SETTINGS frame < 256 bytes long) or just "00 00 12 04 00 00 00 00 00" (initial SETTINGS frame exactly 0x12 bytes long, which is what Nginx apparently does in practice).

Some of the later parts of the response vary slightly, but I unfortunately didn't save any other responses, and I haven't read enough of the RFC to know what the later parts mean.

(Nor have I read Nginx's implementation.)

Edit: Ah, the HTTP/2 response you posted today is exactly the same as the one I did...