On Wed, 21 Nov 2007, Alessandro Vesely wrote:

>> HTML pages with dynamic form input names are very rare so the need for
>> dynamicly encodes of names should be much less frequent.
>
> Even if they are static, they may be complicate, e.g. the Java-generated
> stuff that Bart exemplified a couple of days ago.

So are you then advocating that we should encode the name part as well?

>> I don't see why post data is any special here than all other kinds of
>> operations you do with curl?
>
> So that one can learn how to encode the static name in the script, even
> if it's not curl's job.

You can still do that as you said with -vG or with --trace/--trace-ascii so I
don't think we need to add terrible kludges for this.

> BTW, the syntax is slightly over-restrictive: --data-urlencode "stuff" gives
> "option --data-urlencode: is badly used here", which looks rather
> unnecessary.

That's why I've tried to discuss the syntax of the option... :-)

> The CGI mandates a name=value syntax, but http accepts any input.

Yes, but HTTP doesn't require URL encoding of the data either...

> I would patch it as attached, to urlencode any argument.

I think that syntax has a downside we should rather work around. Here's my
thinking:

Let's say you write a shell script that wants to pass just about anything to a
web site, URL encoded without doing it "name=contents" style. The script gets
the data from a user, or some other external source and it can be just about
anything... Then the data can very well contain a '@' or '=' letters, and
--data-urlencode "$data" will then act very "funny".

I would rather then make it accept "=" or "@" as the first letter in the
argument and then it would not use a name or '=' in the output buffer but
simply encode the whole data chunk or the whole file name.

Or what do you say? Would you mind adjusting the patch to something like this?
Oh, and please poke on the man page too at the same time!

> This is a possibly related, yet different problem. Usually, one does not
> care to bombard a server with sending attempts (which may be good testing
> anyway.) However, if one needs to be careful and wants to test a command
> before issuing it, and does not have a test server at hand, there are not
> many ways to proceed. The latter problem seems even more marginal than the
> former. Perhaps using "file://-" for output could solve both of them?

I guess we'd need some kind of --dry-run option that would output as much as
possible about the request-to-be-done but without actually doing it...

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.

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