Re: [SECURITY ADVISORY] curl invalid URL parsing with '#'
Date: Sun, 6 Nov 2016 18:59:40 -0500
On 11/6/2016 3:34 AM, Kamil Dudka wrote:
>> >Yes now if the path doesn't start with a slash one is added  so it's
>> >going to be rebuilt like
>> >* Rebuilt URL to:file:///
>> >I'm not sure that this is a bug, it seems more correct than it was
> Then what is the correct way to reference a file by its relative path using
> libcurl andfile:// ?
There is none, as far as I understand . A conceptual relative file
URL doesn't have an //authority or even a scheme it is supposed to be
based on another URL. A file URL with a relative path does not seem to
be allowed . In Windows you can get somewhat of a relative path if
you specify the drive letter but don't put a slash after the colon (in
other words don't start from the root of the drive):
If your current directory of the x drive is x:\foo then that gets
x:\foo\a\b. But something like file:///./a/b is correctly (I believe)
interpreted on Windows as <current drive>:\a\b
There is more detail on this relative / absolute difference in my answer
to Mike, below.
On 11/6/2016 1:55 PM, Mike Crowe wrote:
> 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.
RFC 3986 says :
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
authority = [ userinfo "@" ] host [ ":" port ]
path-rootless = segment-nz *( "/" segment )
(mailers may mess this formatting up so note the slashes on separate
lines are separate items, in other words there's no starting // in
heir-part if path-rootless for example.) The same RFC also says:
'The "file" URI scheme is defined so that no authority, an empty host,
and "localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.'
What's interesting is the file URL scheme as it was originally defined
in RFC 1738  isn't explicitly redefined in this RFC 3986 and the
above statement does not conflict with it. In fact the later RFC leaves
the individual schemes up to their respective specifications (and I
can't find any other spec). So assume the same format of
file://<host>/<path> (with the exception noted above that <host> can
For arguments sake though let's say that we allow a relative path URI
scheme for files. Well then I guess you could do file:foo/bar if file
allowed rootless paths and that meant those paths were relative.
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. 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.
List admin: https://cool.haxx.se/list/listinfo/curl-library
Received on 2016-11-07