Skip to content

Support IP CIDR ranges in NO_PROXY - #1165

Open
turettn wants to merge 2 commits into
pydantic:mainfrom
turettn:no-proxy-cidrs
Open

Support IP CIDR ranges in NO_PROXY#1165
turettn wants to merge 2 commits into
pydantic:mainfrom
turettn:no-proxy-cidrs

Conversation

@turettn

@turettn turettn commented Aug 26, 2026

Copy link
Copy Markdown

Summary

From #1164:

The comments for get_environment_proxies implies that CIDRs are supported in the NO_PROXY environment variable:

        # NO_PROXY=.google.com is marked as "all://*.google.com,
        #   which disables "www.google.com" but not "google.com"
        # NO_PROXY=google.com is marked as "all://*google.com,
        #   which disables "www.google.com" and "google.com".
        #   (But not "wwwgoogle.com")
        # NO_PROXY can include domains, IPv6, IPv4 addresses and "localhost"
        #   NO_PROXY=example.com,::1,localhost,192.168.0.0/16

Unfortunately, they aren't actually respected. If you use the NO_PROXY string from the comment, and connect to http://192.168.0.10, it will still attempt to go through the proxy.

The NO_PROXY string is currently being properly translated to a URLPattern (e.g. 192.168.0.0/16 => all://192.168.0.0/16), but the URLPattern matcher doesn't handle the CIDR.

This PR is an attempt to fix the matching logic.

Unit tests provide full code coverage. scripts/test passes. As an additional sanity check, this used to fail with "connection refused" since the proxy doesn't exist, but now works on my branch:

HTTPS_PROXY=http://localhost:12345 NO_PROXY=10.128.0.0/16 python -c "import httpx2; httpx2.get('https://10.128.11.39/')"

The most questionable part of this PR is how URLPattern ordering should work. "Check smaller ranges before larger ranges" seems reasonable. "IP addresses & ranges before hosts" seemed like basically a coin flip, so I just picked one.

This is my first PR to httpx2, so if I violated any conventions or you'd like any changes, just let me know. Thanks!

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.

Since this brings the behavior in line with the documentation (or at least the comments), and I don't see any references to NO_PROXY in the docs, I skipped this step. If you'd like a change added, just let me know.

Review in cubic

@codspeed-hq

codspeed-hq Bot commented Aug 26, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 17 untouched benchmarks
⏩ 7 skipped benchmarks1


Comparing turettn:no-proxy-cidrs (c482d7e) with main (4c02c4b)

Open in CodSpeed

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.

@turettn
turettn marked this pull request as ready for review August 26, 2026 17:41
@mbeijen

mbeijen commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

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 cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

Re-trigger cubic

Co-authored-by: Michiel W. Beijen <mb@x14.nl>
@turettn

turettn commented Aug 26, 2026

Copy link
Copy Markdown
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants