On Tue, 2010-06-08 at 11:02 +0530, Saisatish vedam wrote: > On Mon, Jun 7, 2010 at 6:48 PM, Oleg Kalnichevski <[email protected]> wrote: > > > On Mon, 2010-06-07 at 11:52 +0530, Saisatish vedam wrote: > > > Hi, > > > > > > I need to construct a multipart/mixed request with > > > (a) Set Content-type hdr (along with charset) for individual mime part > > > (b) Encode filename in the Content-Disposition hdr's using that charset > > (ex: > > > for multibyte file names). > > > > > > Using http-components 4.0, I extended MultiPartEntity > > > (generateContentType()) to create a request with multipart/mixed > > > content-type. > > > I achieved (a) by extending InputStreamBody to provide getCharset(), mode > > as > > > STRICT. > > > > > > However there seems to be no easy way to achieve (b) as the > > > content-disposion filename is encoded using the charset only in > > > BROWSER_COMPATIBLE mode. > > > Unfortunately, the relevant methods in MultiPartEntity cannot be > > > overriden/extended as it uses private final instances of HttpMultiPart > > (and > > > why ?). > > > > > > Seems like writing a new class (ex: MultipartMixedEntity) implementing > > > HttpEntity - which then uses an extended HttpMultipart seem to be the > > only > > > solution and this adds a *lot* of redundant code. And this seems to be > > no > > > different wit 4.1 alpha as well > > > > > > > Sometimes, when bastardizing a standard, one might need to write some > > redundant code. > > > > > Indeed. Especially, when one is dealing with many such rogue products. > > > > > > > > Any other ideas ? > > > > > > > How about using a MIME standard compliant encoding scheme such as BASE64 > > or quoted-printable encoding as recommended by RFC 2047 and RFC 2231? > > > > I don't have that luxury as the rogue server doesn't understand them. But > then, that is my problem. > > An observation on the MultipartEntity though: > > A protected - HttpMultipart generateHttpMultipart() - makes > MultipartEntity more extensible than it is today. And if the intention was > not to allow usage of extended HttpMultipart then that should've been final. >
Saisatish You are very welcome to propose changes to the MultipartEntity class preferably by submitting a patch against SVN trunk. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
