Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of hablutzel1@gmail.com
 designates 74.125.82.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFxNpv-6wsp+GwbFQGjfafJ=w=ciotbZQekcu0imCzw3Ufc+JQ@mail.gmail.com>
References: 
 <CAFxNpv-6wsp+GwbFQGjfafJ=w=ciotbZQekcu0imCzw3Ufc+JQ@mail.gmail.com>
From: Jaime Hablutzel Egoavil <hablutzel1@gmail.com>
Date: Mon, 11 Mar 2013 20:22:27 -0500
Message-ID: 
 <CAFxNpv9NC7JAi2h4-ANHaBJb9NcDHN8mLP1XJwhOje0=mdn8ug@mail.gmail.com>
Subject: Re: Wrong processing for encoding of Content-disposition 'filename'
 parameter
To: dev@commons.apache.org
Content-Type: multipart/alternative; boundary=e89a8f64337298f43c04d7b02056

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

nothing on this?


On Fri, Mar 8, 2013 at 10:38 AM, Jaime Hablutzel Egoavil <
hablutzel1@gmail.com> wrote:

> 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?
>
> Take a look at this issue too and see if you can reopen it:
>
> https://issues.apache.org/jira/browse/FILEUPLOAD-56#comment-13597224
>
>
> PS: Chrome and Firefox browsers doesn't seem to follow this spec neither
> as they encode 'filename' parameter (from a multipart/form-data) with the
> page encoding (or form accept-charset), thus producing headers with raw
> UTF-8 or any encoding choosen for the page in some cases.
>
>
>
> --
> Jaime Hablutzel -  RPC 987608463
>


-- 
Jaime Hablutzel -  RPC 987608463

--e89a8f64337298f43c04d7b02056--