On Wed, 21 Nov 2007, Alessandro Vesely wrote:

Thanks for the patch, I've committed it!

> I've had an attempt. I found no other way than indenting to convey the idea
> that mixing --data-* options joins them with '&'. Thus I messed up the whole
> --data section. (I didn't run roffit on it, so please check links, if you
> like the changes.)

I liked the changes, but I did edit them slightly before I committed.

[about having --dry-run or similar option]

>> I think it is a good idea, but I think we'll need to bang on the library
>> a bit too then since a lot of what is sent in a typical request is not
>> quite known to curl but is simply left for libcurl to setup and do.
>
> Some parts of it. Of course, that will have to be done thinking at how
> a generic client program may benefit for it. Sounds good for testing.
>
> I'll have to check the "file://" behavior. It is barely (un)documented for
> the CURLOPT_URL API parameter. Apparently, curl can read from a file url,
> but doesn't write to it. And "file://-" doesn't read stdin.

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?

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.

"file://-" is not a valid URL so it won't work. In fact there's no way to
specify stdin with a URL so you can't make curl read from stdin using a URL.
Of course we can make libcurl do it if there's really a demand for it, but is
there really?

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