"control H" <[EMAIL PROTECTED]> writes:
> After a few hours of headache I found out my --post-data option
> didn't work as I expected because the data I send has to be
> URL-escaped. This is not mentioned both in the manpage and inline
> help. A remark would be helpful.
Note that, in general, it doesn't. POST requests are a generic
mechanism for transferring data, and a valid POST request can contain
an (unencoded) XML document or even binary data in its body. URL
encoding is only necessary when transferring HTML form data from a
client to the server. Wget doesn't assume that this is the case --
the POST options are designed as a low-level tool which the user is
expected to understand how to use.
I now see that this is not the most useful design for most people; for
one, the manual could at least document the typical usage. It is also
inconsistent because Wget automatically sends "Content-Type:
application/x-www-form-urlencoded" when one of the POST options is in
use, which indicates that the primary usage for POST was uploading
form data.
One way to solve this is to introduce higher-level functionality, such
as --form-data and --form-attach (for uploading files) which construct
a POST request suitable for sending form data, so the user doesn't
have to. In that case --post-data and --post-file would no longer
need to set content-type to application/x-www-form-urlencoded.
