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
>> name=urlencoded-content
>>
>
> 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 "coolfiles=@fil1.gif"

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:

   --data-urlencode field=$moo

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

Exactly!

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