You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2007/04/07 04:17:38 UTC
Handling content-transfer-encoding encoding and multipart requests with httpcomponents
Hi,
I am writing this as a followup to
http://issues.apache.org/jira/browse/FILEUPLOAD-131
This issue request is about handling content-transfer-encoding with
commons-fileupload.
In this request, Oleg Kalnichevski explains:
> I doubt HttpCore would be of any use here, as it does not (and is not supposed to)
> provide any content codecs. You probably may want to take a closer look at
> Commons Codec, which provides two content transfer codecs mentioned in
> RFC1521: quoted-printable and base64. Some efforts will have to spent on
> getting those codecs to work with I/O streams, though.
I have studied the charta of the HttpComponents and find this
statement most possibly caused by the following sentence:
Jakarta HttpComponents MUST be content agnostic. The project DOES NOT
develop components intended to produce or consume content of HTTP messages.
I would like to ask to rethink this opinion, at least partially:The
httpclient project provides support for creation of multipart
requests. This support is still content agnostic, apart from the fact
that a very widespread packaging mechanism is used.
IMO, the server side should at least support the same level that the
client side does. The content encoding and, in particular, the
content-transfer-encoding cannot be viewed as independent from the
HTTP protocol. Supporting typical cases like multipart/form-data
should at least be provided as a sample implementation.
If you cannot agree with my opinion, I'd like to ask how you would
handle such cases like multipart parsing in your own code. What MIME
or other libraries would you use or recommend?
Thanks,
Jochen
--
My cats know that I am a loser who goes out for hunting every day
without ever returning as much as a single mouse. Fortunately, I've
got a wife who's a real champ: She leaves the house and returns within
half an hour, carrying whole bags full of meal.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart
requests with httpcomponents
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-04-07 at 12:45 -0700, Jochen Wiedmann wrote:
>
> Hi, Roland,
>
>
> Roland Weber-3 wrote:
> >
> >
> > I'd have a look at commons-fileupload and javax.mail. Obviously
> > commons-fileupload doesn't work for you.
> >
> >
>
> it may surprise you that I currently am the single active developer of
> commons-fileupload. 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.
>
> 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?
>
Jochen,
I believe so, as MIME is supposed to be a transport agnostic content
coding standard. At any rate as far as HTTP is concerned multipart
encoded requests are just blobs.
Oleg
>
> Thanks,
>
> Jochen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart requests
with httpcomponents
Posted by Ortwin Glück <od...@odi.ch>.
Roland Weber wrote:
>> 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?
MIME was originally specified for email. That's why it is called
"Multipurpose Internet *Mail* Extension". See RFC 2045.
The only requirement of MIME to the transport level is that it must
provide a possibility to transport the toplevel MIME meta information:
MIME version, the content type and the boundary string. Both SMTP and
HTTP embed this into their respective headers. Other than that I know of
no protocol specifics. A MIME implementation should leave this link to
its transport protocol up to the caller, to not restrict the use of the
library to a certain protocol.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart requests
with httpcomponents
Posted by Roland Weber <os...@dubioso.net>.
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart
requests with httpcomponents
Posted by Jochen Wiedmann <jo...@gmail.com>.
Hi, Roland,
Roland Weber-3 wrote:
>
>
> I'd have a look at commons-fileupload and javax.mail. Obviously
> commons-fileupload doesn't work for you.
>
>
it may surprise you that I currently am the single active developer of
commons-fileupload. 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.
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?
Thanks,
Jochen
--
View this message in context: http://www.nabble.com/Handling-content-transfer-encoding-encoding-and-multipart-requests-with-httpcomponents-tf3539561.html#a9887235
Sent from the HttpComponents-Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart requests
with httpcomponents
Posted by Roland Weber <os...@dubioso.net>.
Hello Jochen,
> http://issues.apache.org/jira/browse/FILEUPLOAD-131
> [...]
> I have studied the charta of the HttpComponents and find this
> statement most possibly caused by the following sentence:
>
> Jakarta HttpComponents MUST be content agnostic. The project DOES NOT
> develop components intended to produce or consume content of HTTP
> messages.
>
> I would like to ask to rethink this opinion, at least partially:The
> httpclient project provides support for creation of multipart
> requests. This support is still content agnostic, apart from the fact
> that a very widespread packaging mechanism is used.
The charta was not imposed upon us. We developed it, and there are
good reasons for limiting the scope:
- there are too few developers, they couldn't cover a wider scope anyway
- there are other Apache projects, and we must not get into their turf
Getting HTTP right is hard enough on it's own. Work on HttpComponents
has started more than two years ago, and there is not even a first
alpha of the new HttpClient 4.0. Why should we consider extending our
scope in this situation?
> IMO, the server side should at least support the same level that the
> client side does.
No way. There are standardized APIs for server-side HTTP communication,
in particular the Servlet API - which is implemented in Tomcat, one of
those other projects in whose turf we must not get. There are no such
standardized APIs for the client side - except HttpURLConnection, which
is so limited that the HttpClient project was started in the first place.
> The content encoding and, in particular, the
> content-transfer-encoding cannot be viewed as independent from the
> HTTP protocol. Supporting typical cases like multipart/form-data
> should at least be provided as a sample implementation.
Multipart form-data can be used to generate files as well as
HTTP message entities. Why should it be tied to the HTTP protocol?
If I am not mistaken, multipart MIME messages were developed for
email communication in the first place.
> If you cannot agree with my opinion, I'd like to ask how you would
> handle such cases like multipart parsing in your own code. What MIME
> or other libraries would you use or recommend?
I'd have a look at commons-fileupload and javax.mail. Obviously
commons-fileupload doesn't work for you.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart
requests with httpcomponents
Posted by Jochen Wiedmann <jo...@gmail.com>.
olegk wrote:
>
>
> The original plan with regards to the multipart encoding was and still
> is to factor it out of HttpClient and move it to Commons Codec. There is
> already a project to that end [1] which unfortunately got stalled. We
> have never had any multipart decoding / parsing code in HttpClient in
> the first place, so I wanted to approach FileUpload folks with a request
> to contribute their multipart decoding code to Codec to make the
> multipart codec feature-complete.
>
> Commons Codec already provides BASE64 and quoted-printable codecs needed
> for the content-transfer-encoding support. To me it would also make
> sense to develop mulpitart coding / decoding code out of Commons Codec.
>
>
I understand that that makes sense. I am personally not so keen with commons
codec, because it doesn't provide any streaming API's, although there are
plenty of such API's within the ASF, that might be borrowed. I'll keep this
in mind, though.
Thanks,
Jochen
--
View this message in context: http://www.nabble.com/Handling-content-transfer-encoding-encoding-and-multipart-requests-with-httpcomponents-tf3539561.html#a9887272
Sent from the HttpComponents-Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Handling content-transfer-encoding encoding and multipart
requests with httpcomponents
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-04-07 at 04:17 +0200, Jochen Wiedmann wrote:
> Hi,
>
> I am writing this as a followup to
>
> http://issues.apache.org/jira/browse/FILEUPLOAD-131
>
> This issue request is about handling content-transfer-encoding with
> commons-fileupload.
>
> In this request, Oleg Kalnichevski explains:
>
> > I doubt HttpCore would be of any use here, as it does not (and is not supposed to)
> > provide any content codecs. You probably may want to take a closer look at
> > Commons Codec, which provides two content transfer codecs mentioned in
> > RFC1521: quoted-printable and base64. Some efforts will have to spent on
> > getting those codecs to work with I/O streams, though.
>
> I have studied the charta of the HttpComponents and find this
> statement most possibly caused by the following sentence:
>
> Jakarta HttpComponents MUST be content agnostic. The project DOES NOT
> develop components intended to produce or consume content of HTTP messages.
>
> I would like to ask to rethink this opinion, at least partially:The
> httpclient project provides support for creation of multipart
> requests. This support is still content agnostic, apart from the fact
> that a very widespread packaging mechanism is used.
>
> IMO, the server side should at least support the same level that the
> client side does. The content encoding and, in particular, the
> content-transfer-encoding cannot be viewed as independent from the
> HTTP protocol. Supporting typical cases like multipart/form-data
> should at least be provided as a sample implementation.
>
> If you cannot agree with my opinion, I'd like to ask how you would
> handle such cases like multipart parsing in your own code. What MIME
> or other libraries would you use or recommend?
>
>
> Thanks,
>
> Jochen
Hi Jochen,
The HttpComponents charter was made so restrictive primarily to please
some Tomcat folks who viewed the project as promoting unnecessary
competition within ASF. Lots of things changed since those days. ASF now
hosts projects that directly compete with one another, so a revision of
the charter is certainly due.
Having said that, I personally think we should stay focused on HTTP
aspects and depend on external libraries for things such as content
coding.
The original plan with regards to the multipart encoding was and still
is to factor it out of HttpClient and move it to Commons Codec. There is
already a project to that end [1] which unfortunately got stalled. We
have never had any multipart decoding / parsing code in HttpClient in
the first place, so I wanted to approach FileUpload folks with a request
to contribute their multipart decoding code to Codec to make the
multipart codec feature-complete.
Commons Codec already provides BASE64 and quoted-printable codecs needed
for the content-transfer-encoding support. To me it would also make
sense to develop mulpitart coding / decoding code out of Commons Codec.
I also beleive Apache JAMES provides a complete MIME library of its own,
which _may_ already have a complete set of codecs needed for the
content-transfer-encoding support.
I hope this makes our position clearer.
Cheers
Oleg
[1]
http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org