Support IP CIDR ranges in NO_PROXY

[turettn]

NO_PROXY entries with a CIDR range were turned into all://192.168.0.0/16, but URLPattern ignored the /16. So NO_PROXY=192.168.0.0/16 bypassed the proxy only for 192.168.0.0 itself, and proxied the other 65,535 addresses. IPv6 ranges like fe80::/10 behaved the same way.

Discussed in #1164.

What changed

• URLPattern matches IPv4 and IPv6 networks, e.g. all://192.168.0.0/16, all://[fe80::]/10. This applies to NO_PROXY and to mounts.
• Bracketed IPv6 networks in NO_PROXY, like [fe80::]/64, are accepted.
• A network is only accepted when written exactly as IP/digits or [IPv6]/digits, like curl and Go do. Anything else, e.g. 10.0.0.0/33, 127.0.0.1/8/../0, 127.0.0.1:8080/8, 10.0.0.0/8? or [fe80::1%eth0]/64, is ignored in NO_PROXY and raises InvalidURL in mounts.
• Mount priority: exact hosts match before networks, smaller networks before larger ones, and networks before catch-all patterns like all://. Host length no longer breaks ties between equal networks, so the scheme does.

Behaviour changes

• Requests to addresses inside a NO_PROXY range now go direct instead of through the proxy.
• mounts keys with an IP host and an invalid network now raise InvalidURL instead of matching only that host.

AI Disclaimer

This PR was developed with the assistance of either Claude or Codex. I've reviewed and verified the changes.

[codspeed]

Merging this PR will not alter performance

✅ 17 untouched benchmarks
⏩ 7 skipped benchmarks¹

---

_{Comparing turettn:no-proxy-cidrs (8757e40) with main (cd50836)}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[mbeijen]

Thanks, this looks good, can you maybe add two more parametrized tests:

("all://[fe11::]/16", "http://[fe11:1234::5]", True),
("all://192.168.0.10/16", "http://192.168.5.10", True),  # host bits set

This expands test coverage, I think might be helpful

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[turettn]

Thanks, this looks good, can you maybe add two more parametrized tests:

("all://[fe11::]/16", "http://[fe11:1234::5]", True),
("all://192.168.0.10/16", "http://192.168.5.10", True),  # host bits set

This expands test coverage, I think might be helpful

@mbeijen Both added - good thinking!

[ofilip]

The same functionality is already present in older PR #969 (which is backported from: encode/httpx#3741)

[cubic-dev-ai]

All reported issues were addressed across 3 files

<sub>Reply to a comment to ask cubic a question or push back. It learns from your replies.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[turettn]

@Kludex Thanks for merging this, and sorry it took so much extra work!