Daniel Stenberg wrote:
> On Wed, 21 Nov 2007, Alessandro Vesely wrote:
>
> Thanks for the patch, I've committed it!

Pleased to serve you :-)

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

Hmm, I tried to keep those border cases out of the way, to minimize the
chances of annoying regular users of that option...

> [about having --dry-run or similar option]
>
> 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.

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

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

> "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?

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://-

would turn curl into a command line URL encoder. A similar operation
might otherwise be done by

   curl --data-urlencode "=$foo" --get file://notused 2>&1 |\
     sed s'/^.*Couldn.t open file ..\(.*\)/\1/'

but the latter is not something I'd suggest to write in a manual :-/

However, deciding that POST writes might break existing code. A libcurl
client that parses server responses may be reading known files after
POSTs to test that a given text is parsed correctly, e.g. to implement
a simple test suite without having to write a server counterpart.
Changing curl's behavior for just "file://-" won't break much stuff,
since it is not currently valid. It may seem rational, as "-" is the
only "standard file" (in some sense) that one can read after writing
in a question-response fashion.

Anyway, I'm not sure how much we need it...
Received on 2007-11-22