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.

>> curl can both read and write to file:// URLs, but to write to it you
>> need to do an "upload" with curl terms and thus use -T etc exactly like
>> you do uploads to other protocols.
>
> When POSTing, one writes before getting a reply, much like PUT. The current
> behavior looks rather a GET, e.g. "curl -d foo file://in" just reads the
> content of that file, irrespective of post data.

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.

> Deciding that POST will write rather than read urls, would bring the
> possibility to check what data one is going to send.

But what does POST to a file:// URL mean? POST is a HTTP style request, it
implies HTTP...

> One advantage of "file://-" is that one doesn't have to worry about
> arbitrarily overwriting existing files. When used for output as above, it
> makes it easier to experiment curious command lines without hassle. For
> instance
>
> curl --data-urlencode "=$foo" file://-

But now you just want to see the url-encoded chunk, you don't actually want to
send a POST to a file, right? So I think you're trying to come up with a
functionality you don't want as a means to provide the functionality you do
want. That's doing it all a bit backwards if you ask me.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html