On Sunday 06 November 2016 at 13:40:58 +0100, Daniel Stenberg wrote:
> Conclusion:
>
> file:// didn't work very good for relaive file paths before this commit
> either, only in a single case for exactly the current directory. The story
> is now much more consistent since all cases seem to work the same way.

I discovered this when I attempted to add a curl test for the file:// case
and couldn't traverse into the logs subdirectory like test200 does. :(

So, I accept that whilst this is a change in behaviour, it only affects a
the narrow case of files in the current directory and such cases should
just be fixed.

The question now is whether the post-3bb273db7e behaviour of treating
file://README as file:///README is sensible, or whether such a URL should
be treated as malformed. I certainly continue to find it confusing that
file://vmlinuz refers to /vmlinuz but file://etc/passwd refers to /passwd.

Maybe once that's decided I can try and write a test for it to add to the
testsuite. :)

Thanks for analysing the problem.

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