Re: Warning: using file:// on Windows with curl
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.