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

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Sep 2013 11:34:24 -0000

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

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

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

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 13:58:13 +0200

On 2013-09-19 13:34, Dave Cridland wrote:
> 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.

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

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

Best regards, Julian