Subject: [apps-discuss] Feedback on multipart/form-data

From: Larry Masinter <[email-masked]>
Date: Thu, 15 Aug 2013 11:28:39 -0700

I'm working on a revision to  RFC 2388 multipart/form-data 
but I want some feedback before submitting a first draft.

I sent a pointer before, 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8

but perhaps you can comment instead on 
     https://github.com/masinter/multipart-form-data

RFC 2388 was clear:
   Field names originally in non-ASCII character sets may be encoded
   within the value of the "name" parameter using the standard method
   described in RFC 2047.

For reasons I don't understand, browsers did different, incompatible
things. 

I think the main advice is: 

* those creating HTML forms 
   SHOULD use ASCII field names, since deployed HTML processors vary,
   and field names shouldn't be visible to the user anyway.

* Those developing server infrastructure to read multipart/form-data uploads
   SHOULD be aware of the varying behavior of the browsers in translating
   non-ASCII field names, and look for any of the variants (if they're 
   expecting non-ASCII field names). 

* Those developing browsers should migrate toward a standard 
  encoding, but the server infrastructure will still have to do
  fuzzy match for a long while.

What should the browsers migrate to?

 http://www.rfc-editor.org/rfc/rfc5987.txt 
seems like a more recent proposal and possibly implemented in HTTP anyway.

Sites that use non-ASCII field names and want to work with multiple
browsers already have to do fuzzy matching.

The problem is that the fuzzy matchers already deployed might not
recognize any *NEW* encodings.

So I suppose having a name* value would be necessary.