commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [fileupload] Expected encoding for Content-disposition 'filename' parameter
Date Tue, 12 Mar 2013 09:23:49 GMT
On Thu, Mar 7, 2013 at 11:14 PM, 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?
>

Hi,

this is a known problem, see
https://issues.apache.org/jira/browse/FILEUPLOAD-199

Hopefully this will be fixed soon.

Thomas


>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message