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

[Julian Reschke <[e-mail]>]

On 2013-09-19 13:34, Dave Cridland wrote:
> Julian Reschke wrote:
>> 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?
>
> RFC 2047 doesn't discuss parameters; though at least some mail MIME
> generators use it, instead of RFC 2231. (Google, for instance, generates
> mail using RFC 2047 encoded-words in parameters, but accepts either RFC
> 2047 or RFC 2231 encoded parameters).

Yup, it's wide-spread in mail, but not used a lot on the web.

>>>     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
>
> That's all well and good, but filenames are considerably more of a
> problem, I'd have thought. Moreover, I think existing HTTP clients don't
> escape '"' properly, as well.

Yes. There's also the issue clients not escaping backslashes in path 
names. (IE?)

>>>     * 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?
>
> I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and
> unencoded ISO-8859-1 (I think).

No surprise here :-)

> I'd also note that I've yet to find a receiving processor that handles
> multipart/form-data when chunked - I'll admit I've not been looking
> much, though. It might be as well to note the interaction with chunked
> encoding.
>
> Sent with [inky: <http://inky.com?kme=signature>]

Best regards, Julian