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

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Sep 2013 14:43:07 -0000

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.

Sent with [inky: <http://inky.com?kme=signature>]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Sep 2013 11:08:04 -0400

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

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Sep 2013 18:07:07 +0200

On 2013-09-20 17:08, Phillip Hallam-Baker wrote:
> ...
> We should definitely try to clean up multipart/form-data but we should
> try to build a long term transition path to JSON.
> ...

Replacements for the both form upload media types would be cool, but 
then, how to get them deployed?

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 20 Sep 2013 22:30:03 +0200 (CEST)

> industry is going. JSON already has full compliance with UTF-8 etc.

I'll take this opputunity to remind readers that multipart/form-data is 
*WIDELY* used by non-browsers as well. And those non-browsers may not all have 
any JSON awareness at all.

-- 

  / daniel.haxx.se