cURL / Mailing Lists / curl-library / Single Mail


Re: [SECURITY ADVISORY] curl invalid URL parsing with '#'

From: Mike Crowe <>
Date: Sun, 6 Nov 2016 18:55:43 +0000

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.

List admin:
Received on 2016-11-06