Am Tuesday 16 April 2013 schrieb Daniel Stenberg:
On Sun, 14 Apr 2013, Tim Rühsen wrote:
I wanted to propose that we use Content-Type: multipart/form-data and
send the whole file as-is when using the --body-file option. This
allows us to add the long missing functionality to send files as
attachments through wget, without having to change the working of the
old options.
Why not look at curl (see --form) and decide, if it is the optimum or if
there is a better way for the user to specify what he wants to upload.
And then implement the best option syntax.
I'm the main author of the -F logic for curl so I'm very biased here. But
let me just provide some data. (And I don't think --form syntax curl uses
is the optimum interface, it is just one I made up some 10-12 years ago
and we've stayed with it to maintain compatibility - and it works pretty
good.)
multipart/form-data posts consis of one or more parts, where most HTML
forms use more than one. To allow a tool to mimic a browser fine, you need
to be able to fill in the other parts as well as the file upload (and you
can even nest the parts, and for example upload multiple files within a
single part). Users also occasionally want to alter the headers for
specific form parts. (RFC1867 has all the details on the format.)
I use curl's --form for multi-file uploads (+ several key/value pairs) since
2005 and changed 2010 to curl library. So I am aware of you and curl ;-)
BTW, thanks for that awesome tool.
For some closed source projects I wrote a MIME parsing/compositing library
that is used for email and HTTP stuff. Just said to clarify that I am aware of
what we are talking here.
From RFC 1867:
The media-type multipart/form-data follows the rules of all multipart
MIME data streams as outlined in RFC 1521
The boundary string Giuseppe mentioned isn't really such a big deal if you
ask me. You can easily make it in the same style as the browsers do it (a
- prefix and a series of random letters) and if you like curl use
12 random hex letters it still makes 184884258895036416 possible combos.
Sorry, I don't see the point here.
Guiseppe talked about the *user* specifying the boundary (if I correctly
understood that).
Wget should care for these details and just automatically create a boundary
(similar to what you suggested above). But that's details.
The main task would be to provide a user interface to specify as many MIME
parts as the user wants in one upload. And it is worth looking at how curl
does it - as you say, it works pretty good.
This includes the possibility to specify --body-file as often as needed and
also to specify the Content-Type.
Base64 encoding is already existent in Wget, boundary creation is simple,
recursive MIME structure isn't needed so far, MIME parsing isn't needed.
So Wget already has everything to compose multipart/form-data bodies. We just
have to throw it together.
Regards, Tim
