Hello Jochen, > it may surprise you that I currently am the single active developer of > commons-fileupload.
It does :-) > My thinking was, that multipart parsing and stuff like > that is a generic issue and should be decoupled from file uploads. Agreed. > HttpComponents still seems to me to be the logical place where to look for > such things, at least at a conceptual level. If you consider multipart only for HTTP entities, yes. But multipart is more general than that, too. > Javax.mail might be an alternative. Indeed, Geronimo is even providing an > implementation within the ASF. Can anyone advice me, whether MIME encoding > within emails and in HTTP messages can be mapped 1:1? I don't have a definitive answer, but this is what I found: RFC 2388, multipart/form-data: However, multipart/form-data can be used for forms that are presented using representations other than HTML (spreadsheets, Portable Document Format, etc), and for transport using other means than electronic mail or HTTP. This document defines the representation of form values independently of the application for which it is used. RFC 2557, multipart/related: While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. HTML 4.01: The content "multipart/form-data" follows the rules of all multipart MIME data streams as outlined in [RFC2045]. http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2 Looks like it is supposed to be independent of the transfer protocol. Which does not protect you from unpleasant surprises of course. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
