noproxy tail matching still has an issue

[sthen]

Contrary to https://github.com/curl/curl/blob/master/tests/unit/unit1614.c#L88, traditional behaviour for no_proxy is for example.com to also match host.example.com.

I did this

$ curl -V
curl 7.86.0 (x86_64-unknown-openbsd7.2) libcurl/7.86.0 LibreSSL/3.6.0 zlib/1.2.13 nghttp2/1.50.0
Release-Date: 2022-10-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe UnixSockets

$ no_proxy=google.com https_proxy=http://127.0.0.1:9999/ curl -sI https://www.google.com/ | head -5
curl: (7) Failed to connect to 127.0.0.1 port 9999 after 0 ms: Couldn't connect to server

I expected the following

$ curl -V
curl 7.85.0 (x86_64-unknown-openbsd7.2) libcurl/7.85.0 LibreSSL/3.6.0 zlib/1.2.12 nghttp2/1.49.0
Release-Date: 2022-08-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe UnixSockets

$ no_proxy=google.com https_proxy=http://127.0.0.1:9999/ curl -sI https://www.google.com/ | head -5
HTTP/2 200 
content-type: text/html; charset=ISO-8859-1
p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
date: Wed, 02 Nov 2022 03:13:12 GMT
server: gws

As also seen in at least lynx, w3m, OpenBSD ftp(1).

curl/libcurl version

[see above]

operating system

OpenBSD $somehostname 7.2 GENERIC.MP#819 amd64

[sthen]

(I should add, adding commits efc286b and b830f9b doesn't help)

[bagder]

That is however how the functionality has been documented for curl for a very long time. The CURLOPT_NOPROXY docs from 7.85.0 says:

If the name in the noproxy list has a leading period, it is a domain match against the provided host name. This way ".example.com" will switch off proxy use for both "www.example.com" as well as for "foo.example.com".

[bagder]

Added to the docs in 2d5fa35 it seems.

[sthen]

The lines just above that say "For example, example.com would match example.com,
example.com:80, and www.example.com, but not www.notanexample.com or
example.com.othertld."

[bagder]

Hah, yes it does. So, total confusion...

[hawicz]

This is a major breaking change from version 7.85.0 and earlier and is causing a fair number of issues because existing no_proxy settings that have worked for years no longer do so. I would argue that the original issue was a documentation bug, and the pre-existing behavior should have been retained.
Also, with the new version the order of entries in no_proxy matters, no_proxy=example.com,.example.com works as expected, but no_proxy=.example.com,example.com incorrectly tries to use the proxy.

Can we please revert to the original behavior and update the man page instead?

[sthen]

FWIW, the reason I noticed this is because I have a couple of dozen machines which had curl in the pipeline for checking for updates to packages, and after updating to 7.86.0 for the IDN security fix they were no longer able to do so because they relied on no_proxy to reach the relevant server. I've since changed how they do things, but wanted to mention it as an example of one type of problem that can be caused by this.

If it is going to stay like this, then at least an explicit note in release notes would be appreciated.

[bagder]

I will appreciate if you help me verify if #9858 brings back the old logic proper.