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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Sep 19, 2013 at 10:43 AM, Dave Cridland <[e-mail]> wrote:

> Julian Reschke wrote:
>
>> On 2013-09-19 15:29, Dave Cridland wrote:
>>
>>>     Julian Reschke wrote:
>>>
>>>>
>>>>>     I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and
>>>>>     unencoded ISO-8859-1 (I think).
>>>>>
>>>>
>>>>     No surprise here
>>>>
>>>
>>>     Yes, but one wonders if the unencoded UTF-8 actually does any harm at
>>>     all in a 8bit/binary-safe protocol like HTTP.
>>>
>>>     If most processors accept this - and I have no idea - it might even
>>> be
>>>     useful to document.
>>>
>>
>> The risk here is that some UAs send ISO-8859-1 (or something based on the
>> locale), and servers parse based on the User-Agent. We have the same
>> problem with the Content-Disposition response header field.
>>
>> It's hard to change these kinds of workarounds in deployed code, and
>> that's why a new mechanism that can't be confused with the old syntax may
>> work better (thus RFC 5987).
>>
>
> Yes, agreed, though UTF-8 is very difficult to accidentally mimic, from
> what I've found.
>
> I wonder if an EAI expert might suggest something here? Or if a top-level
> parameter or header might be useful to indicate UTF-8 header content? I
> can't help but feel it's a simpler construct to adhere to.
>
>
I think it is useful to do whatever we can to standardize
multipart/form-data. But it is going to be an imperfect solution.

Every browser already has to support JSON in practice. JSON is where the
industry is going. JSON already has full compliance with UTF-8 etc.


We should definitely try to clean up multipart/form-data but we should try
to build a long term transition path to JSON.

-- 
Website: http://hallambaker.com/