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

[Julian Reschke <[e-mail]>]

On 2013-08-15 20:28, Larry Masinter wrote:
> 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.

Insane complexity? :-) Too many ways to do the same thing?

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

+1

> * 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).

If this is a SHOULD we need to better understand what these variants 
are. Study standard libraries? Write tests?

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

+1

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

Also, they probably vary on User-Agent.

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

Indeed.

We had the same conversation for Content-Disposition (the HTTP header 
field), and in the those UA vendors opposed to RFC2231/5987 gave up and 
implemented it (IE, Chrome, Safari).

Best regards, Julian