[p3ck]

Summary

Fixes no_proxy to support IPV6 CIDR format.

no_proxy=fe11::/16 python -c 'import httpx; c = httpx.Client()'

Closes: #3221

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[ofilip]

Hi, thanks for this PR. I found this httpx issue 6 months ago and wanted to address it since then. Your change only makes httpx not crash when an IPv6 range is in no_proxy but it is not properly handled. I build upon your work and addressed the issue with extending URLPattern functionality with ip range handling with ipaddress.ip_range.

I did not manage to push or create a PR to your branch so at least I'm sharing the commit: 92067fe

EDIT: PR is here: p3ck#1

It is also not yet properly tested as I didn't manage to run all tests. I only managed to run tests I modified.

[p3ck]

@ofilip Thank you for the great work. Can you check the changes I made to get it to pass linting and testing?

Thanks

[ofilip]

@ofilip Thank you for the great work. Can you check the changes I made to get it to pass linting and testing?

Thanks

I reviewed your commits and everything seems in place. Thx a lot for review, tests and improvements.

[p3ck]

@lovelydinosaur Any chance this could be included in a bugfix release for the current code before 1.0?

[ege-arhan]

In IPNetPattern.__init__:

self.net = ipaddress.ip_network(ip_net)

ipaddress.ip_network defaults to strict=True. If an environment sets a CIDR entry containing non-zero host bits (e.g. NO_PROXY=192.168.1.5/24 or NO_PROXY=[fe80::1]/64), ipaddress.ip_network raises ValueError: ... has host bits set.

In build_url_pattern:

def build_url_pattern(pattern: str) -> Pattern:
    try:
        proto, rest = pattern.split("://", 1)
        if proto == "all" and "/" in rest:
            return IPNetPattern(rest)
    except ValueError:
        pass
    return WildcardURLPattern(pattern)

When IPNetPattern raises ValueError, build_url_pattern silently falls back to WildcardURLPattern("all://192.168.1.5/24"), which cannot match host 192.168.1.5 because it treats /24 as a URL path component.

Passing strict=False in IPNetPattern:

self.net = ipaddress.ip_network(ip_net, strict=False)

masks host bits and allows valid CIDR subnet matching even when a specific IP within that subnet is provided in NO_PROXY.

[Howard-Jerry]

Tested this branch against a bracketed, non-CIDR IPv6 literal, which is not hypothetical: a desktop app I use appends [::1] to NO_PROXY machine-wide for every child process (it needs the bracketed form for undici's matcher).

Installed head 83d203a into a clean venv and compared:

no_proxy	0.28.1	this branch
fe11::/16	InvalidURL: Invalid port: ':'	OK
[::1]	InvalidURL: Invalid port: ':1]'	still InvalidURL

$ no_proxy='[::1]' python -c 'import httpx; httpx.Client()'
httpx.InvalidURL: Invalid port: ':1]'

The bracket stripping added in _utils.py sits inside the CIDR branch:

if addr[0] == "[" and addr[-1] == "]":
    addr = addr[1:-1]
    ip_net = f"{addr}/{range}"

so a bracketed literal without a prefix never reaches it and still fails.

Would you consider normalizing a bare bracketed literal (strip [/], then treat it as a single address) in the same change? Otherwise the same crash class survives this fix — and since the variable is machine-wide, it takes down every httpx client in every process, not just proxy lookups.

Happy to open a separate issue with the full traceback if you'd rather keep this PR focused on CIDR.

[OKAN-SOFTWARE]

I noticed a potential ordering issue with overlapping CIDR patterns.

IPNetPattern.priority currently returns the same (-1, 0, 0) value for every network. Since mounts are sorted by priority and the first matching pattern determines the transport, overlapping CIDR entries are resolved by insertion order rather than network specificity.

For example:

mounts = {
    "all://10.0.0.0/8": broad_transport,
    "all://10.1.0.0/16": specific_transport,
}

Both patterns match http://10.1.2.3/, but the /8 entry takes precedence when listed first.

Could we incorporate self.net.prefixlen into the priority so the longest matching prefix wins? A regression test with overlapping networks in both insertion orders would help ensure consistent routing behavior.

The existing tests cover individual CIDR matches but don't appear to exercise this case.