On Sun, 6 Nov 2016, Ray Satiro via curl-library wrote:

> As this relates to libcurl file://foo probably has the most logical
> treatment file://foo/ , however given the need for backwards compatibility I
> suppose it should be changed it back and have a test. Is it right Daniel
> your vote is still +1 for that, I can't tell.

No. Since "going back" only fixes a specific use case but still leaves
relative paths basically not working, I think the way forward is to leave that
code as it is. It makes the behavior more consistent and there's just no
relative access for file:// URLs - apart from the peculiar windows effect when
using drive letter without slash.

> Regardless I think we should probably be more restrictive here if we aren't
> going to allow hostnames in file: to instead treat any file://foo/bar as an
> error even if we allow file://foo. What libcurl has been doing stripping out
> the first part silently does not seem like a good idea, because it's
> misleading the user who may think either of file://foo/bar is actually /bar
> coming from foo or that it's a local foo/bar or /foo/bar.

Agreed. As I just responded to Mike Crowe, I think we should only allow a
blank or localhost in the host name field.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html