Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of hablutzel1@gmail.com designates
 74.125.82.50 as permitted sender)
MIME-Version: 1.0
From: Jaime Hablutzel Egoavil <hablutzel1@gmail.com>
Date: Thu, 7 Mar 2013 17:14:25 -0500
Message-ID: 
 <CAFxNpv9Hy_0TnZy_WMVVytH+nLHtKTwkLem7ax7u5d4YgGj7xw@mail.gmail.com>
Subject: [fileupload] Expected encoding for Content-disposition 'filename'
 parameter
To: user@commons.apache.org
Content-Type: multipart/alternative; boundary=089e010d8574bacaaa04d75d087f

--089e010d8574bacaaa04d75d087f
Content-Type: text/plain; charset=ISO-8859-1

I'm looking that commons fileupload uses a 'headerEncoding' variable which
Javadoc explanes:

Specifies the character encoding to be used when reading the headers of
> individual part. When not specified, or null, the request encoding is used.
> If that is also not specified, or null, the platform default encoding is
> used.


Well, this headerEncoding is responsible for decoding the 'filename'
parameter value too, but I can see that rfc1867 (the RFC you implement)
says:

 The original local file name may be supplied as well, either as a
>    'filename' parameter either of the 'content-disposition: form-data'
>    header or in the case of multiple files in a 'content-disposition:
>    file' header of the subpart. The client application should make best
>    effort to supply the file name; 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.  This is a
>    convenience for those cases where, for example, the uploaded files
>    might contain references to each other, e.g., a TeX file and its .sty
>    auxiliary style description.


So the filename parameter value should not be decoded without any mechanism
but US-ASCII  or the method described in RFC 1522 (encoded words), but you
just decode it with a custom 'headerEncoding'. So please any clarification
would be useful to me, why are you processing headers like that?

PS: Chrome browser doesn't seem to follow this spec neither as it does
encode 'filename' parameter (from a multipart/form-data) with the page
encoding, thus producing headers with raw UTF-8 or any encoding choosen for
the page in some cases.


-- 
Jaime Hablutzel -  RPC 987608463

--089e010d8574bacaaa04d75d087f--