Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: Non-ascii filenames in Multipart POST
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
In-Reply-To: <47C3EBED.8030505@andywu.co.uk>
References: <47C2F163.6070802@andywu.co.uk>
	 <1204014876.5647.19.camel@ubuntu>  <47C3EBED.8030505@andywu.co.uk>
Content-Type: text/plain
Date: Tue, 26 Feb 2008 20:13:42 +0100
Message-Id: <1204053222.5772.21.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Tue, 2008-02-26 at 10:37 +0000, Andy Wu wrote:
> Hi Oleg,
> 
> Appreciate the prompt response.
> 
> Do you know what the correct method is of sending filenames containing 
> non-ascii chars?
> 
>  From what I've read in http://www.faqs.org/rfcs/rfc1867.html:
> 
>     "if the file name of the client's operating system is not in
>     US-ASCII, the file name might be approximated or encoded using the
>     method of RFC 1522"
> 
> Which to me equates to encoding the filename using 
> javax.mail.internet.MimeUtility.encodeText(). The software I'm uploading 
> to however doesn't decode the filename. Neither do other upload servlets 
> such as http://www.servlets.com/cos/ and 
> http://commons.apache.org/fileupload/index.html.
> 

This is hardly surprising since most (all) of the server side upload
libraries are geared mostly towards compatibility with web browsers
rather than standards compliance. 

If you are not willing to use HttpClient 4.0, the only thing I can think
of is writing a custom request entity for Httpclient 3.x based on Apache
mime4j

Hope this helps

Oleg 


> Thanks
> Andy Wu
> 
> Oleg Kalnichevski wrote:
> > On Mon, 2008-02-25 at 16:48 +0000, Andy Wu wrote:
> >   
> >> Hi,
> >>
> >> When making a multipart post uploading a file with a filename containing 
> >> non-ascii characters, the filename appears to be incorrect written to 
> >> the http request.
> >>
> >> If you look at the code, sendDispositionHeader() essentially sends the 
> >> filename.getBytes( "US-ASCII" ):
> >>
> >>   
> >> http://hc.apache.org/httpclient-3.x/xref/org/apache/commons/httpclient/methods/multipart/FilePart.html
> >>
> >> However, the browsers I've tested with will send the filename.getBytes( 
> >> "ISO-8859-1" ) version of the filename and thus the software that's I'm 
> >> working with that receives the upload is decoding the filename correctly.
> >>
> >> Would anyone else concur that this is a bug?
> >>
> >>     
> >
> > Andy,
> >
> > This is definitely not a bug. Non-ASCII characters are not allowed to be
> > present in the MIME elements such disposition headers. Common browser
> > applications violate the MIME spec. Plain and simple.
> >
> > For those who do not give a flying damn about standards compliance,
> > HttpClient as of release 4.0-alpha3 provides a browser compatibility
> > mode for multipart coded entities.   
> >
> > Hope this helps
> >
> > Oleg
> >
> >   
> >> Thanks
> >> Andy Wu
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>
> >>
> >>     
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org