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
{{ message }}
Repository navigation
Inconsistent handling of IPv6 scope in SocketsHttpHandler's connection pool #135103
Confirmed on .NET 10.0.12: changing a scoped IPv6 proxy from %1 to %2 still selects %1 in ConnectCallback, even when the first connection attempt failed. This reproduces with HTTP, HTTPS, and SOCKS5 proxies for both HTTP and HTTPS requests.
A targeted fix can make proxy pool keys scope-sensitive while retaining canonical URI equivalence. Changing Uri.Equals globally should be considered separately because it changes URI-keyed collection behavior.
Activity
dotnet-policy-service commentedon Oct 2, 2026
Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.
wfurt commentedon Oct 2, 2026
I'd be in favor. I don't even think it is breaking change. We do use scope for
IPAddress.makazeu commentedon Oct 10, 2026
Confirmed on .NET 10.0.12: changing a scoped IPv6 proxy from %1 to %2 still selects %1 in ConnectCallback, even when the first connection attempt failed. This reproduces with HTTP, HTTPS, and SOCKS5 proxies for both HTTP and HTTPS requests.
A targeted fix can make proxy pool keys scope-sensitive while retaining canonical URI equivalence. Changing Uri.Equals globally should be considered separately because it changes URI-keyed collection behavior.
Working on a fix for proxy pool keys.
Note
This analysis was generated with GitHub Copilot.
MihaZupan commentedon Oct 11, 2026
I disagree, I think fixing this in Uri would be cleaner.
makazeu commentedon Oct 12, 2026
Working on raising another PR to fix
Uri.EqualsUpdate:
PR done: #135617