W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 09 Jul 2012 23:28:09 +0200
Message-ID: <4FFB4CE9.8040002@gmx.de>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@lists.whatwg.org, Evan Jones <evanj@csail.mit.edu>, Anne van Kesteren <annevk@opera.com>
On 2012-07-09 23:01, Ian Hickson wrote:
> On Thu, 3 May 2012, Evan Jones wrote:
>> On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
>>> Yes. I think we should define multipart/form-data directly in HTML and
>>> thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated
>>> and not maintained.
>> Right; that would be ideal. Despite the fact that HTML5 references that
>> RFC, browsers don't really follow it.
>> I would be interested in trying to help with this, but again I would
>> certainly need some guidance from people who know more about the
>> vagaries of how the various browsers encode their form parameters /
>> uploaded file names, and why things got that way. It probably would not
>> be helpful for me to try to draft an update to the spec without getting
>> the right implementers on board.
> If this is still something for which you have some time available, then
> the starting point for anything like this would be test cases, lots and
> lots of test cases. In this case, it would have to be something like a
> server that echoes the precise bytes sent by the client, for a huge
> variety of different setups:
>   - various submission encodings
>   - various form field names and types
>   - various file submission filenames
> ...etc.
> I'd be happy to advise if this is something that still interests you.

I agree with the methodology. However I would suggest to simply revise 
RFC 2388.

Best regards, Julian
Received on Monday, 9 July 2012 21:28:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC