https-eyeballing async#21267
Closed
icing wants to merge 4 commits into
Closed
Conversation
Make cf-https-connect work async correctly: - only start first baller when at least one A/AAAA address is available - select first connect attempt after that with HTTPS-RR info there or not. - select second connect attempt only when HTTPS-RR is resolved (may have resolved to "not known") and select possible ALPN from things known by then. May not select any second attempt when first already covers everything. This means when the HTTPS-RR is known at/before the first address is resolved, everything behaves as before. When the HTTPS-RR is late, a first connection attempt will have been started. Any ALPN preference from the HTTPS-RR that is not already ongoing will then start the second attempt. For HTTPS-RRs that recommend 2 or more ALPNs, the first will always be attempted: either it is already ongong or it will be the ALPN for the second attempt. The 2nd ALPN recommendation from HTTPS-RR *may* be honored or not, depending on what is already selected. The difference in behaviour between early/late HTTPS-RR resolve cannot be helped - unless we do not perform any attempts before it arrives. Trade offs.
bagder
approved these changes
Apr 8, 2026
There was a problem hiding this comment.
Pull request overview
This PR updates the HTTPS-CONNECT “eyeballing” logic to behave correctly when HTTPS-RR information arrives asynchronously, so initial connection attempts can start as soon as an A/AAAA is available while still honoring later HTTPS-RR ALPN guidance when it becomes known.
Changes:
- Reworked
cf-https-connectstate machine/baller selection to defer choosing the second attempt until HTTPS-RR is resolved. - Added a DNS helper (
Curl_conn_dns_has_any_ai) to detect when at least one address is available before starting connection attempts. - Improved the HTTP/3-over-UNIX-socket failure path to emit a proper error message.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| lib/cf-https-connect.c | Major refactor of async “eyeballing”/ALPN attempt selection and connection state handling |
| lib/cf-dns.c | Adds Curl_conn_dns_has_any_ai() helper for partial async DNS availability |
| lib/cf-dns.h | Declares the new DNS helper API |
| lib/vquic/vquic.c | Emits a failf() error message for HTTP/3 over UNIX domain sockets |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Make cf-https-connect work async correctly:
This means when the HTTPS-RR is known at/before the first address is resolved, everything behaves as before. When the HTTPS-RR is late, a first connection attempt will have been started. Any ALPN preference from the HTTPS-RR that is not already ongoing will then start the second attempt.
For HTTPS-RRs that recommend 2 or more ALPNs, the first will always be attempted: either it is already ongong or it will be the ALPN for the second attempt. The 2nd ALPN recommendation from HTTPS-RR may be honored or not, depending on what is already selected.
The difference in behaviour between early/late HTTPS-RR resolve cannot be helped - unless we do not perform any attempts before it arrives. Trade offs.