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