On 11/6/2016 3:34 AM, Kamil Dudka wrote:
>> >Yes now if the path doesn't start with a slash one is added [1] 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
>> >before.
> 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 [1]. 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 [1][2]. 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):

curld file:///x:a/b

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 [1]:

    URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
    hier-part = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

    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 [2] 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
disappear).

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.

[1]: https://tools.ietf.org/html/rfc3986#appendix-A
[2]: https://tools.ietf.org/html/rfc1738#section-3.10

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