Daniel Stenberg
Daniel Stenberg
> The current solution (protocol://localhost/path/to/file) is based on the assumption that filenames are unixy I would rather say that it is based on the fact that a URL contains both...
> The idea is that a double leading slash also works for unixy absolute paths, and this way there is no need for a Windows-specific hack But that changes previous...
> > I would rather say that it is based on the fact that a URL contains both a hostname and a path and this takes advantage of that. >...
> I wasn't proposing breaking the command-line, but instead introducing something portable that can replace the non-portable one in all envs. Sorry, I didn't get that. How would that work?
We could solve it differently. Right now, setting `CURLOPT_UNIX_SOCKET_PATH` implies using unix domain sockets *to the server* (not proxy) and using a proxy together with this is a reason for...
> though why hostname and filename are necessary at the same time is something I don't grok Because that is how we added support for unix domain names to proxies....
> This works fine as long as the filename is compatible with an URL path part. This is also means it doesn't work on Windows. It does not work, no,...
I spent 10 minutes just now trying to find out how colons *should* be treated in this weirdo system but I failed. I don't know the correct way. The [canon_string](https://github.com/curl/curl/blob/9b6148e9d95db54a752b03b571296c40d66e97fe/lib/http_aws_sigv4.c#L508)...
We need to find the detailed explanation/spec for how the canonicalization of that part of the URL is meant to work for sigv4. I couldn't find it. Then we need...