Httpx: HTTP/3 support.

[jlaine]

It would be nice to start planning support for HTTP/3. aioquic provides a sans-I/O API for HTTP/3 similar to h2 which would make such an integration possible.

The main hurdle is that the connection model is very different to HTTP/1.1 and HTTP/2 : we cannot simply establish a (reader, writer) pair over a TCP connection and pass this to the protocol layer. Between the HTTP/3 layer and the UDP transport, we have a QUIC layer which returns (datagram, addr) tuples indicating where datagrams need to be sent:

https://aioquic.readthedocs.io/en/latest/quic.html#aioquic.quic.connection.QuicConnection.datagrams_to_send

Note that the destination address may change during the connection's lifetime, for example in response to receiving a PreferredAddress from the server during the TLS handshake.

In order to provide a first demonstration, @tomchristie suggested I write a dispatcher which makes use of aioquic's HTTP/3 support. The code is still a bit rough, but it works:

https://github.com/aiortc/aioquic/blob/master/examples/httpx_client.py

This can be run as:

python examples/httpx_client.py https://cloudflare-quic.com/

[jlaine]

I'm not too sure how to move this forward. Ideally I'd like to have a WIP pull request which we can rebase / amend until we're happy with the result. However I haven't really got a feel for how the code should integrate with httpx's connection management. Any hints on how to approach this problem?

[sethmlarson]

We'll need to add UDP support to our backend interface, that's definitely step 1.

After that we need to see how we want to implement client storage so we can remember things like Alt-Svc headers between requests.

Next would be landing an HTTP/3 specifier along with the H3Connection dispatcher. I'm not sure how compatible aioquic is with an SSLContext object (probably not at all?) so that will take some tweaking. And because HTTP/3 is known to not work in some routes we'll have to implement "fallback to TCP and forget the H3 alt svc" on the HTTPConnection object somehow.

Anything I'm missing @encode/httpx-maintainers?

[florimondmanca]

I don't know enough about HTTP/3 to tell (for example, I'm not sure what the differences between QUIC and HTTP/3 and the associated aioquic APIs are?), but the approach highlighted by @sethmlarson sounds sensible to me.

One thing I'm sure of is that we'll need to chunk this into multiple PRs, otherwise we risk ending up with a 1000 LOC+ PR that's a pain for everyone to look at. That way we can more easily track progress too.

We'll need to add UDP support to our backend interface, that's definitely step 1.

Yup, and UDP support is definitely going to be a big chunk.

HTTPX is currently very much coupled to TCP. In particular, right now a given HTTPConnection doesn't know about other connections, but from what you've said it seems like a QUIC "connection" needs to know about the surrounding connections to do packet routing (though it might be a defining property of UDP?), correct? Anyway, there'll be some refactoring needed before supporting UDP to clarify what is TCP-specific and what is not.

After that we need to see how we want to implement client storage so we can remember things like Alt-Svc headers between requests.

I think this should be an improvement over a basic design, right? (Under the hypothesis that remembering Alt-Svc headers will only allow us to skip the protocol switching phase of establishing an HTTP/3 connection.)

So, in terms of planning, I tried to think about the various steps in a bit more detail. I could see something like:

1. Rename BaseStream / Stream / ConcurrencyBackend.connect() to BaseTCPStream / TCPStream / ConcurrencyBackend.connect_tcp().
2. Add UDP support. This will most likely include building an UDP version of TCPStream and the associated methods on ConcurrencyBackend. At this point, the resulting updated ConcurrencyBackend (with an asyncio implementation) can be unit-tested against a very basic asyncio UDP server.
3. Add httpx.dispatch.http3.HTTP3Connection, an HTTP/3 implementation via aioquic. To reduce the scope of this step, we can set some constraints:
   
   
   
   • HTTPConnection.connect() should try to connect via HTTP/3 and create a UDPStream / H3Connection if and only if HTTP/3 is one of the given http_versions (e.g. Client(http_versions=["HTTP/3"]). This way, we don't need to think about Alt-Svc and the switch between TCP and UDP yet.
   
   
   • All QUIC connections can be stored on H3Connection directly (similar to how we have one h11.H1Connection on our H1Connection class), without thinking about sharing those connections yet (provided we need to share those at all?).
   
   
4. Add Alt-Svc support: always connect via TCP first, and only if Alt-Svc is received then establish a newH3Connection. (Will this require to modify HTTP11Connection and HTTP2Connection so that they are able to process Alt-Svc header in the response? Is raising an exception in HTTP11Connection.send() and HTTP2Connection.send() and catching it in Connection.send() a sensible enough way of signalling we should reconnect via UDP-HTTP/3?)
5. Optimize connection making by remembering Alt-Svc headers.
6. Implement sharing of QUIC connections between HTTPConnections — if relevant?

---

Some resources I've come across:

• HTTP/3 Explained: https://http3-explained.haxx.se/en/
• asyncio UDP client example: UDP Echo Client
• Trio UDP discussion w/ usage hints: https://github.com/python-trio/trio/issues/537
• Hypercorn initial implementation: https://gitlab.com/pgjones/hypercorn/commit/7c1f519fe117f3fbcc6a62fcccdae2e8dfe0b61a

[sethmlarson]

Lots of great info @florimondmanca!! 🎉

I'm going to chime in here again at the idea of using AnyIO and adding our stream interface to that?

[florimondmanca]

I'm going to chime in here again at the idea of using AnyIO and adding our stream interface to that?

As in, using AnyIO (see #296) to provide an ConcurrencyBackend.connect_udp() implementation for all backends on top of their UDP sockets API? I'm not against the idea but it might be a bit too much for this particular issue. It could be a preliminary step but we haven't decided yet on whether we should switch over to AnyIO.

Edit: also, since AnyIO mandates the same "strict context management everywhere" approach than Trio, it's highly probable we'd need to refactor some internals to comply with that requirement. One item in particular is the Stream interface, which trio/AnyIO primarily expose as a context manager, although it's possible to .aclose() manually.

[jlaine]

HTTPX is currently very much coupled to TCP. In particular, right now a given HTTPConnection doesn't know about other connections, but from what you've said it seems like a QUIC "connection" needs to know about the surrounding connections to do packet routing (though it might be a defining property of UDP?), correct? Anyway, there'll be some refactoring needed before supporting UDP to clarify what is TCP-specific and what is not.

I don't see why the different connections should have any kind of coupling. The most straightforward approach is going to be opening a distinct UDP socket for every QUIC/HTTP3 connection so there will be a one-to-one mapping between socket and QUIC/HTTP3 connection.

At a high level, an HTTP3 connection is going to be very similar to an HTTP2 connection: you can run any number of requests on top of your connection.

I _think_ this should be an improvement over a basic design, right? (Under the hypothesis that remembering Alt-Svc headers will only allow us to skip the protocol switching phase of establishing an HTTP/3 connection.)

HTTP3 support has landed in cURL and more recently in Chrome/canary so I'd suggest looking into how they handle Alt-Svc.

Some resources I've come across:

You might want to add aioquic's demo HTTP client:

https://github.com/aiortc/aioquic/blob/master/examples/http3_client.py

[cdeler]

I tried to follow the guide written by @tomchristie above.

The first step was

Rename BaseStream / Stream / ConcurrencyBackend.connect() to BaseTCPStream / TCPStream / ConcurrencyBackend.connect_tcp().

It has been implemented in https://github.com/encode/httpx/pull/339
Having found the PR and the changes, I wanted to look around it and found that neither BaseTCPStream nor TCPStream nor ConcurrencyBackend are presented in httpx/httpcore repos. Moreover the file structure of he repo has significantly changed from the PR.

@florimondmanca , @tomchristie
Do you have a time to provide us with advice, where the process should start? Should it be some sort of new connection to httpcore._async/httpcore._sync with the aioquic backend?

Update
Probably the first step might be to add "open_quic_connection" to existing backends?

[tomchristie]

@cdeler Well, it's about as complex as you could get for a contribution, but if you're up for it then I can certainly put in the guidance for a sensible way to approach it.

The keyword here, as with anything like this, will be incremental. 😀

• I'd start off with a pull request that just adds an http3 flag to the ConnectionPool configuration, in the same way as the existing http2 flag. It should also be passed through to the HTTPConnection instance. To begin with it shouldn't actually do anything, it should simply be there.
• ~The next step could be to "notice" if an HTTP/3 service is advertised. If an HTTP/1.1 or HTTP/2 connection gets a response with an Alt-Svc: h3 header, and if http3=True has been set, then a NotImplementedError exception should be raised.~

At that point we've got a stub behaviour for detecting HTTP/3 support, which we can start to iterate on.

[cdeler]

The keyword here, as with anything like this, will be incremental. 😀

it's smart behaviour to make incremental changes, I'm happy to try doing that

[tomchristie]

Slight update - let's scratch the second part of that, actually I think we'll want to use the HTTP/2 frame-type ALTSVC to detect if we should upgrade or not.

We'll use that because we don't want to wait for response headers before we decide on if we should upgrade. The ALTSVC frame can be sent during the opening handshake, before the request itself is made. We'll probably need to end up doing some investigation into exactly when implementations choose to send this frame, before we're able to proceed from there.

[tomchristie]

It's looking to me like httpx should never end up making an HTTP/3 request on an initial outgoing request, because either:

• We see the upgrade in an Alt-Svc response headers, in which case we've already sent the request, and started receiving the response, not much point in tearing the connection down.
• We might potentially see an ALTSVC HTTP/2 frame, but we don't want to block on waiting for that before starting to send a request (since it may not exist).

So I think the best we'll be able to do is storing altsvc information whenever it comes through, and potentially making subsequent requests over HTTP/3 using that information.

[cdeler]

@tomchristie

Have you seen this example in the aioquic repo?

[florimondmanca]

@cdeler — Sure, it was posted by Jeremy (OP) in the issue description. :-) Obviously looks outdated by now since some bits of HTTPX API have changed, but I'm sure it's been discussed earlier in this thread?