i.e. an extra slash, making the host part of the URL empty. This is similar to how a file: URL would refer to the same file.

Unfortunately, the URL parser accepts one, two or three slashes where there should be two so three slashes will be accepted as if they were two:

$ curl -x socks5h:///moo/hello localhost
curl: (7) Failed to connect to moo port 1080 after 0 ms: Connection refused

Another option is to use a short but otherwise illegal host name. For example just two dots (..):

$ curl -x socks5h://../run/tor/socks localhost
curl: (6) Could not resolve host: ..

That sounds wrong—it goes against RFC 1738 and RFC 8089, anyway. Is this a WHATWG thing?

Yes. 😢 The lax nature of WHATWG's URL spec makes such URLs occasionally get used in the wild, so this is our adjustment to accept such URLs better.The WHATWG spec actually allows any amount of slashes (even zero), and both backslashes and slashes (mixed) but curl only allows regular forward slashes and only one, two or three of them.

For tests, I think test case 1435 can serve as good inspiration as it already uses --unix-socket

I looked at the test setup. I think the following changes are required along with writing a testcase.

1. Update this server to support taking unixsocket as argument. https://github.com/curl/curl/blob/master/tests/server/socksd.c
2. Pass the option from here: https://github.com/curl/curl/blob/master/tests/runtests.pl

Q: Where should the temporary socket be created and how/when should it be cleaned up?

With last update, If the hostname is unix and path is not just '/', the path is considered to to be a unix socket.

Please correct if I am missing anything.

@bagder Please take a look again.

• Changed syntax to socks5h://localhost/path/to/sock
• Added tests

I don't understand the torture test failure but it does not fail consistently.

The torture test fail of 1467 means that there is a memory/resource leak somewhere in the exit path.

The torture test fail of 1467 means that there is a memory/resource leak somewhere in the exit path.

Reviewed again. Could not find the leak.. Can you please share instructions to reproduce failure locally? I am on a ubuntu desktop. make tests-full pass fine.

Added documentation for the command line flags.

The clue is torture tests. It's a special way to run the tests, which verifies the exit paths heavily.

Reviewed again. Could not find the leak.. Can you please share instructions to reproduce failure locally? I am on a ubuntu desktop. make tests-full pass fine.

$ ./configure --enable-debug (+ c-ares or non-threaded resolver)
$ make
$ cd tests
$ make
$ ./runtests -n -t 1467

This then makes all allocations in the test fail, one by one and it verifies that it never leaks memory in any case.

The 1467 failure you got looked like this:

test 1467...[HTTP GET via SOCKS5 proxy via unix sockets]
 144 functions found, but only fail 25 (17.36%)
** MEMORY FAILURE
Leak detected: memory still allocated: 10 bytes
At 7f7f53e04bc8, there's 10 bytes.
 allocated by escape.c:144
LIMIT urlapi.c:1415 strdup reached memlimit
 Failed on function number 93 in test.
 invoke with "-t93" to repeat this single case.

It shows that escape.c:144 allocated a line that was never freed. It was when fallible function number 93 was made to fail. If you wanted reproduce that exact fail number, you can do this:

./runtests -t94 1467

I usually first try with -t to run all loops torture to see that it reproduces, it might not be the exact same number in a local build. Also, use -n to switch off valgrind since running with valgrind makes every loop take several times longer, which can make this test really slow. Using valgrind in the last step when you re-run a single number is very useful because valgrind can help you pinpoint the entire leak call stack much better.

if you still have problems rerunning the test, I can have a go at it soon.

if you still have problems rerunning the test, I can have a go at it soon.

Thank you. Was able to reproduce and fix it. Waiting for CI run.

Fixed torture test and added documentation. Please review. curl/check failure does not show any logs or errors except for message "Build Failed". Please help understand the error.

This looks very good and I'm ready to merge. Just one thing left that I can think of:

You added docs for the command line tool but not for the libcurl option that actually passes the string to libcurl. CURLOPT_PROXY. It needs to be similarly extended so that users can learn how to specify a socks proxy over unix domain socket with it.

Thank you. Updated CURLOPT_PROXY documentation.

Thanks!