Hi Daniel,

perhaps --data-urlencode is a better name for the option?

Daniel Stenberg wrote:
> I've pulled out an old patch I worked on ages ago, and I thought I'd
> freshen it up and perhaps commit if I can get it sensible...
>
> I'm writing this in the hope that you'll provide some feedback on the
> syntax/usage of this new option.
>
> The --data-encode option will do URL encoding of _parts_ of the given
> string so that you can easier write a script that posts data to a web
> site. The usage is currently like this:
>
> --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_.

> It also supports getting the content part from a file, so that you can
> instead write it like this:
>
> --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"

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

> Good/bad? Any obvious cases where we can improve this? Any obvious cases
> where this is not good enough?

I think it's good. The ability to cleanly pass "name=$VALUE" or "date=`date`"
makes it a good option for shell scripts.
Received on 2007-11-04