Support HTTP/2 (httpie-http2 plugin doesn't work)

It’s 2018 now, HTTP/2 is widely used, but httpie still doesn’t support it out of the box. Let’s fix this.

I know about httpie/httpie-http2, but there are issues with this approach:

1. httpie/httpie-http2 doesn’t come out of the box when httpie gets installed, many people would just never know that this plugin even exists.
2. Linux distributions do not provide a package for that plugin.
3. People have issues installing the plugin on macOS: https://github.com/jakubroztocil/httpie/issues/298#issuecomment-273360856.
4. The entire code of httpie/httpie-http2 is just 20 lines (7 useful lines), integration will be trivial.
5. Even curl supports HTTP/2 out of the box.

I see many benefits of supporting HTTP/2 natively. What are the downsides?

[jcayzac]

It’s 2018 now, HTTP/2 is widely used

It’s 2022 now, HTTP/3 is an industry standard…

[tomchristie]

I’d like to pick this up again - I’m planning on releasing httpx/httpcore 1.0 this month, and after that getting HTTP/2 support for httpie is right up there on my list. Because httpie has a super large install base it’s going to be really important to minimise any risk of unintended changes in the network behaviour, even for edge cases etc.

I think the approach in #972 is the smart route to take - continue using requests, but switch the underlying adapter to httpcore in order to support HTTP/2. I’ll have another look at reissuing a pull request for that once httpcore 1.0 is released.

I would probably suggest that the cautious approach would (at least to start with) be to only enable HTTP/2 support when explicitly requested(?) Ie. have an --http2 flag, and only switch to httpcore in that case. The benefit of this is that all existing behaviour will stay the same, which just means a much lower risk factor for any changes.

One other fiddly bits:

• --http2 should imply --default-scheme=https. Or perhaps error unless it’s used with the https command? (Because HTTP/2 is normally HTTPS-only)
• When HTTP/2 support is enabled you don’t actually know if the request will end up being HTTP/2 or HTTP/1.1 until the SSL connection has been established. This means you’ll sometimes end up with the following kind of behaviour…

> https www.http11onlyserver.com --http2
GET / HTTP/2  # <--- Prints as if an HTTP/2 request was sent.
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: www.http11onlyserver.com
User-Agent: HTTPie/2.6.0



HTTP/1.1 200 OK  # <--- But actually the connection ended up on HTTP/1.1
Age: 500630
Cache-Control: max-age=604800
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Thu, 16 Dec 2021 10:32:28 GMT
Etag: "3147526947+gzip"
Expires: Thu, 23 Dec 2021 10:32:28 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECS (nyb/1D04)
Vary: Accept-Encoding
X-Cache: HIT

That can only be resolved by using some hooks to httpcore that provide detailed callbacks, and printing the request once the connection is actually established. But that’d require a much bigger change to httpie, and doesn’t seem worth the complexity for a first-pass.

(Although if you did ever go down that route there’s some useful information you’d be able to start exposing from httpie, but that’s a whole different conversation.)

Anyways - any thoughts? Does this seem like a reasonable approach?