You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came across an edge case testing the example http clients with https://cloudflare-quic.com.
Environment
Network
Carrier Grade NAT
IPv6 enabled network
Device
MacOS 15.2
Python 3.13
httpcore==1.0.7
httpx==0.27.2
aioquic==1.2.0
anyio==4.6.2.post1
https://cloudflare-quic.com has an IPv6 resolvable address which gets returned by getaddrinfo, however, it does not respond to QUIC or TCP packets sent to this address (sometimes). This causes the connection to fail despite getaddrinfo resolving an IPv4 address for the endpoint that does accept QUIC and TCP packets.
This is handled quite gracefully in httpx thanks to httpcores use of anyios connect_tcp function which implements the stateless version of the Happy Eyeballs algorithm outlined in RFC 6555 (aka 'Fast Fallback'). Essentially, if both IPv6 and IPv4 addresses are resolved, it attempts to connect to the IPv6 address first, if it gets a response before some delay (~0.25s) it continues with that connection, otherwise it attempts to create a session with the IPv4 address in parallel, and continues with whichever gets a response first.
Edit: Formatting, clarify Happy Eyeballs description to be more accurate, remove irrelevant sentence.
The text was updated successfully, but these errors were encountered:
I came across an edge case testing the example http clients with
https://cloudflare-quic.com
.Environment
https://cloudflare-quic.com
has an IPv6 resolvable address which gets returned bygetaddrinfo
, however, it does not respond to QUIC or TCP packets sent to this address (sometimes). This causes the connection to fail despitegetaddrinfo
resolving an IPv4 address for the endpoint that does accept QUIC and TCP packets.This is handled quite gracefully in
httpx
thanks tohttpcore
s use ofanyio
sconnect_tcp
function which implements the stateless version of the Happy Eyeballs algorithm outlined in RFC 6555 (aka 'Fast Fallback'). Essentially, if both IPv6 and IPv4 addresses are resolved, it attempts to connect to the IPv6 address first, if it gets a response before some delay (~0.25s) it continues with that connection, otherwise it attempts to create a session with the IPv4 address in parallel, and continues with whichever gets a response first.Edit: Formatting, clarify Happy Eyeballs description to be more accurate, remove irrelevant sentence.
The text was updated successfully, but these errors were encountered: