On Mon, Jun 7, 2010 at 6:48 PM, Oleg Kalnichevski <ol...@apache.org> 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. Thanks anyways. --Sai > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
