Date: Thu, 8 Nov 2007 23:31:03 +0100 (CET)
On Sun, 4 Nov 2007, Alessandro Vesely wrote:
> perhaps --data-urlencode is a better name for the option?
Yes, I think you're right!
>> --data-encode name=content
>> curl will then encode the content part and send this on like
> I don't think the name should be urlencoded. Usually forms have fixed
> variable names and if necessary one can write "funny%20name=$VALUE", if I
> got what you mean by _parts_.
That's what I meant. The name is passed on exactly as given, only the part to
the right side of the '=' gets url-encoded.
>> --data-encode name_at_filename
>> curl will then read the contents from the given file and then encode it
>> and use it like this: name=urlencoded-file-contents
> That's different from, say, curl -F "email@example.com"
Yes it is. The reasoning behind this change is that I imagine using this
option within a shell script or similar, and then we'll use something like:
... and if we for example get some more or less random input in the variable
$moo, we would get some funny effects if $moo would start with the letter '@'.
Thus, I want a clear separation between the encoding of a given string and the
encoding of the contents of a given file.
We can solve the problem in other ways too, but this is what I came up with
and I couldn't figure out any other approach that is clearly better.
>> You can of course mix --data, --data-binary and --data-encode on a command
>> line and you can use any number of either one of them just like before.
> Would that imply a POST or can be used to urlencode GET forms as well?
> Or would an option named just --urlencode better suit the latter case?
Yes, you can encode GET forms too with this, since you can always use -G to
convert a POST into a GET like that.
> I think it's good. The ability to cleanly pass "name=$VALUE" or
> "date=`date`" makes it a good option for shell scripts.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-11-08