url-encoding of POSTed data?
Date: Tue, 18 Nov 2003 16:25:08 -0500
I notice that curl.exe has no option (at least none that I can find) to tell it to url-encode POST data. So, for example, I can't do this:
$ curl.exe --data "Field1=Some Value" <url>
and have the embedded spaces properly preserved all the way through to the ASP page which receives them. With an IIS web server, it seems that the spaces are being stripped out, even though I know curl sent them (I could see them in a --trace-ascii).
Now, I realize that I can manually url-encode this string, as in:
$ curl.exe --data "Field1=Some+Value" <url>
$ curl.exe --data "Field1=Some%20value" <url>
and have it work as expected. But sometimes it's not very pleasant or easy to do the url-encoding myself. Yes, I know there are lots of ways to call a urlencode function, but there are times when it would be nice not to have to hook one up...
Would anyone oppose seeing a new command-line option added, such as this:
--data-encode <data> A single POST param, to be url-encoded (H)
(HTTP) A *single* parameter, to be passed in a POST
request to the HTTP server. All data after the first
non-alphanumeric character (normally an = sign)
will be url-encoded for you by curl. For example,
would be the equivalent of this command:
If the data starts with the letter @, the rest will
be interpreted as a file name to read the data from,
and the data in that file will be url-encoded. So,
to post your data from a file named foobar, you would
use "--data-encode @foobar". The file foobar should
ordinarily begin with a field name followed by =,
such as "field1=some data starts here".
If the data includes an @ sign in place of the usual
= sign (such as "--data field1_at_filename"), then
the file specified by 'filename' will be read in,
url-encoded, and used as the value for this field.
This allows a file to be used as the field value without
needing to contain a field name at the beginning.
Similar to -d/--data, except that --data-encode
accepts only one parameter at a time.
The -G/--get option will turn this into a GET or
HEAD request (as opposed to a POST request), but bear
in mind that some web servers may not like receiving
excessively long URLs...
If this option is used several times, the ones fol-
lowing the first will append data.
Daniel: if you have time to code this up, it would be much appreciated. Otherwise, I'll probably get around to it eventually. At the moment, I just wanted to get this idea documented and ask for some feedback.
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
Received on 2003-11-18