curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Warning: using file:// on Windows with curl

From: Dan Fandrich via curl-library <>
Date: Mon, 16 Mar 2020 21:09:08 +0100

On Mon, Mar 16, 2020 at 07:37:42PM +0000, Norton, Mike via curl-users wrote:
> No, the benefits of supporting "a resource on the local disk" are great. But TIL that "file:" is not supposed to be a synonym for "a resource on the local disk". The benefits of supporting "file:" in its entire meaning are apparently murkier.
> My argument (which, to be clear, I am not very serious about), was that since the "file:" URI scheme is supposed to signify "no particular transfer protocol", then arguably the correct behaviour for a transfer tool might be to have no particular support for it. Because how would one properly implement "nothing in particular"? ;-)

"Nothing in particular" doesn't mean "nothing". At worst, it may mean

> I think the new/original way that Curl interprets "file:" URIs - i.e., "let the OS filesystem figure it out" - is okay. The widespread misconception that "file:" is supposed to mean "a resource on the local disk" is unfortunate, but not Curl's fault. IMO probably the URI scheme should have been named "filesystem:" as opposed to the ambiguous "file:".

I'm in control of the URL I give curl and if I want a resource on the local
disk, I'm careful to give curl a URL that points to that. Without file:
support, there's no way to point to a local file even if I want to. Yes, you
can use file: in such a way that it points to a file elsewhere, but that's a
feature that I'm seldom interested in. RFC8089 is pretty clear about when the
resources a file: URL specifies are on the local file system or not.

Received on 2020-03-16