Does EnvHttpProxyAgent handle leading dot in no_proxy in an optimal way?

[SuperOleg39]

Does EnvHttpProxyAgent handle leading dot in no_proxy in an optimal way?

Current behaviour, for no_proxy: .example.com and no_proxy: *.example.com - requests for example.com will be proxied.

Reference -

undici/test/env-http-proxy-agent.js

Line 318 in 6d912de

test('host suffix', async (t) => {

Proposed behaviour, requests for example.com will bypass proxy, leading dot stripped.

References:

• a good article https://about.gitlab.com/blog/we-need-to-talk-no-proxy/ (looks like this is the only attempt to create http proxy envs specification)
• curl - https://curl.se/docs/tutorial.html
• deno - https://github.com/denoland/deno/blob/6fbce91e40cc07fc6da74068e5cc56fdd40f7b4c/ext/fetch/proxy.rs#L1109 (don't know why there is a comment that behaviour is different with curl)
• bun - https://github.com/oven-sh/bun/blob/6e3359dd16aced2f6fca2a8e2de71f09e0bcb3cb/src/env_loader.zig#L200

[SuperOleg39]

I think we can look at .domain.com and *.domain.com as some kind of legacy syntax, and the tools support this as backward compatibility.

[SuperOleg39]

@10xLaCroixDrinker @Uzlopak Hi! What do you think, is proposed changes valid? Will be glad to contribute.

[metcoder95]

Go for it!

[SuperOleg39]

Go for it!

#4676

Of course possible breaking changes don't look pleasant(