Daniel Stenberg wrote:
> On Thu, 22 Nov 2007, Alessandro Vesely wrote:
>
>>> I don't think file:// needs any particular extra documentation since
>>> it's just another URL and it should work the same as other URLs. Or
>>> am I wrong?
>>
>> Well, I don't think there is such a thing as a "file protocol"
>> standard. Thus that kind of url is usually handled ad hoc, when needed.
>
> RFC1738 section 3.10 defines how a file:// URL works, although it
> doesn't contain much hard info.

I quote it:

   The file URL scheme is unusual in that it does not specify an
   Internet protocol or access method for such files; as such, its
   utility in network protocols between hosts is limited.

> Right, curl doesn't support POSTing to a file:// URL since I don't know
> how that would work. Arguably, curl should instead just refuse to act
> when given that set of options.

I would leave it as-is, in order to avoid breaking existing code.

>> One advantage of "file://-" is that one doesn't have to worry about
>> arbitrarily overwriting existing files.
Also, breaking existing code is not a concern with "file://-"

> [...] That's doing it all a bit backwards if you ask me.

On the opposite, I think it is a bit forward :-)

As nobody else said anything, even when allowed enough time for replying,
we may conclude that the feature is not currently needed. However, we
learned --dry-run and file://- are two possible solutions, if testing a
command line before committing it will ever become a problem...
Received on 2007-11-28