hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: Handling content-transfer-encoding encoding and multipart requests with httpcomponents
Date Sun, 08 Apr 2007 17:42:02 GMT
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.


> 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].

Looks like it is supposed to be independent of the transfer protocol.
Which does not protect you from unpleasant surprises of course.


To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message