hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: multipart/mixed and using mime part's charset in Content-Disposition
Date Tue, 08 Jun 2010 13:40:32 GMT
On Tue, 2010-06-08 at 11:02 +0530, Saisatish vedam wrote:
> On Mon, Jun 7, 2010 at 6:48 PM, Oleg Kalnichevski <olegk@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.
> 

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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message