NO_PROXY entry written as a bracketed IPv6 literal aborts client construction

[NatsUIJM]

What happens

With environment proxy discovery enabled, a NO_PROXY entry that spells an IPv6 address the way a URL does can abort client construction before any request is made.

$ NO_PROXY='[::1]' HTTP_PROXY='http://127.0.0.1:9' python -c "import httpx2; httpx2.Client()"

  File ".../httpx2/_client.py", line 672, in __init__
    URLPattern(key): None
  File ".../httpx2/_utils.py", line 182, in __init__
    url = URL(pattern)
  File ".../httpx2/_urlparse.py", line 390, in normalize_port
    port_as_int = int(port)
ValueError: invalid literal for int() with base 10: ':1]'

httpx2.InvalidURL: Invalid port: ':1]'

httpx2 2.13.1, CPython 3.14.0, macOS arm64. The same value reproduces on httpx 0.28.1, which this fork is based on.

Why

In get_environment_proxies() the two spellings of the same address take different paths:

• ::1 satisfies is_ipv6_hostname() and becomes all://[::1], which is correct.
• [::1] does not, because the brackets are not part of the literal. It also is not localhost, so it falls through to the host-wildcard branch and becomes all://*[::1]. URLPattern then reads that as host *[ with port :1].

The spellings that carry brackets are affected: [::1], [::1]:8080, [::1]/128.

Why a bracketed entry shows up at all

Measured against a local server with the proxy pointed at a dead port:

NO_PROXY entry	CPython 3.14 urllib	undici 8.11.2 EnvHttpProxyAgent	requests 2.34.2
::1	never matches	split into host : + port 1	matches
[::1]	matches	matches	never matches

For urllib, Request('http://[::1]:8080/').host is '[::1]:8080' and _splitport('::1') returns host ':' with port 1; undici's parseNoProxy performs the same split. requests reads urlsplit().hostname, which has the brackets stripped.

So a host that wants IPv6 loopback bypassed across more than one of these stacks ends up writing both spellings. ::1 is fine here; [::1] aborts construction for the clients in that environment that discover proxies from the environment.

Background: what other implementations do with [::1]

no_proxy has no specification, so matching rules are implementation-defined. For this particular entry: Go (x/net/http/httpproxy) strips the brackets and matches on the parsed address; curl hands the entry to inet_pton unchanged, so it fails to parse and never matches; hyper-util (used by reqwest) strips brackets from the URL host, so [::1] ends up in its domain bucket and never matches. I did not find one that raises for this entry. I have not tested every implementation against every malformed entry.

Proposed change

Recognize the bracketed form before the dispatch, so a bare bracketed address produces the same mount as its unbracketed spelling:

if hostname.startswith("["):
    addr, bracket, suffix = hostname[1:].partition("]")
    if bracket and "/" not in addr and is_ipv6_hostname(addr):
        mounts[f"all://[{addr}]{suffix}"] = None
        continue

Scope. For a bare address this produces the same mount as the unbracketed spelling; the bracketed form with a port is described by its own regression cases rather than as an equivalence. The change adds no CIDR/network matching (URLPattern.matches does not consider a prefix length, which is what #969 covers), and it does not make malformed entries safe in general: [not:ipv6] still reaches the wildcard branch, and a non-numeric port such as [::1]:bad still fails to parse.

I have this with tests ready, including client-construction and transport-selection behaviour, and it passes scripts/check and the full suite locally. Would you be open to a narrowly scoped PR for this normalization, leaving malformed-entry handling and CIDR matching as separate questions?

[KevinLee1231]

Corroborating this from an independent setup, on Windows. Same 2.13.1, same traceback, same all://*[::1] mount.

What makes this case show up in practice: the DeepSeek Harness desktop app appends localhost,127.0.0.1,::1,[::1] to NO_PROXY for every shell child process it spawns. Its own source carries this comment (@deepseek-ai/dsh-http-proxy/lib/index.js):

`::1` and `[::1]` are both listed because the resolved string is also handed to undici, whose
matcher reads a bare `::1` as host `:` port `1` and therefore never bypasses it.

The constant there is:

const LOOPBACK_NO_PROXY = ["localhost", "127.0.0.1", "::1", "[::1]"];

So the harness writes both spellings for the interop reason described above, and one shell child ended up with:

no_proxy=.cn,deepseek.com,deepseeksvc.com,gitcode.com,npmmirror.com,zhihu.com,localhost,127.0.0.1,::1,[::1]

urllib.request.getproxies()["no"] returns that string verbatim, brackets included, so it reaches get_environment_proxies() unchanged. The table above still holds as of a few hours ago on this machine — measured with the proxy pointed at a live port:

NO_PROXY entry	CPython 3.14.7 urllib	undici (Node in the harness)	requests
::1	never matches	split into host : + port 1	matches
[::1]	matches	matches	never matches

Concrete consequence in a real workflow: a build helper inside a dev environment aborted at httpx.Client() construction and could not download anything, purely because of that one entry. Unsetting no_proxy for that process made it work immediately, and deleting only [::1] from the list was equally sufficient — ::1 alone is harmless here.

Environment where I reproduced it: Windows 11 x86_64, CPython 3.14.7, httpx2 2.13.1, and httpx 0.28.1 for comparison. I also found a downstream project hitting the same signature: MoonshotAI/kimi-cli#1959, where it crashes on startup and was worked around downstream rather than in httpx2.

No new proposal from me — the normalization you suggested looks right, and I am not asking for anything beyond that.