DoH does not support HTTP/2-only servers

[classabbyamp]

I'm writing a toy resolver that only does DoH over HTTP/2, with the supported protocols advertised over ALPN (i.e., just h2).

It would appear that q (as of v0.19.1) does not support this, and does not send the Upgrade: h2c header either.

Per RFC8484 § 5.2:

HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
with DoH.

So while an HTTP/1.1 DoH server is allowed, it would be good to support HTTP/2.

$ q A placeviolette.net @https://localhost:8443 --trace
DEBU[0000] Server(s): [https://localhost:8443]          
DEBU[0000] Using server https://localhost:8443/dns-query with transport http 
DEBU[0000] Using HTTP(s) transport: https://localhost:8443/dns-query 
DEBU[0000] [http] sending GET request to https://localhost:8443/dns-query?dns=acABAAABAAAAAAAADXBsYWNldmlvbGV0dGUDbmV0AAABAAE 
FATA[0000] requesting https://localhost:8443/dns-query?dns=acABAAABAAAAAAAADXBsYWNldmlvbGV0dGUDbmV0AAABAAE: Get "https://localhost:8443/dns-query?dns=acABAAABAAAAAAAADXBsYWNldmlvbGV0dGUDbmV0AAABAAE": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00*\x04\x00\x00\x00\x00\x00\x00\x01\x00\x00\x10\x00\x00\x02\x00\x00\x00\x00\x00\x04\x00\x00\xff\xff\x00\x05\x00\x00@\x00\x00\b\x00\x00\x00\x00\x00\x03\x00\x00\x00d\x00\x06\x00\x01\x00\x00" 

[franklouwers]

While eac353c added support for http2 via the --http2 flag, http/1 is still the default. While some large DoH resolvers (eg Google DNS) do support http/1, all of them support http/2, and there are plenty of popular DoH software stacks out there which do not support http/1 at all.

Can we inverse the logic by making http/2 the default, and requiring a user to explicitly specify http/1 using a --http1 flag?