[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] [Bug-Wget] Use of maltipart/form-data when using body-fil
From: |
Tim Ruehsen |
Subject: |
Re: [Bug-wget] [Bug-Wget] Use of maltipart/form-data when using body-file command |
Date: |
Tue, 16 Apr 2013 09:27:57 +0200 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
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