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-library Etiquette: https://curl.haxx.se/mail/etiquette.html
