Re: Handling content-transfer-encoding encoding and multipart requests with httpcomponents

[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

Re: Handling content-transfer-encoding encoding and multipart requests with httpcomponents

[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