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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
