On Monday, November 07, 2016 08:45:16 Daniel Stenberg wrote:
> 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.

I agree this is the right approach to take in upstream.

> > 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.

Sounds like a good idea!

Kamil
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-11-07