Download
Browse source Changelog
Documentation
Project   Bug Bounty   Help us   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users Mailing lists Book: Everything curl Video presentations Report a bug Paid support
Development
Autobuilds Code Style Contribute Deprecate Internals Release Notes Release Procedure Roadmap Run Tests Security Process Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-users / 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-users <curl-users_at_cool.haxx.se>
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
unspecified.

> 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.

Dan
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-03-16