Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt

From: Larry Masinter <[email-masked]>
Date: Fri, 20 Sep 2013 10:38:00 -0700

> Is this a difference from application/x-www-form-urlencoded where the
> charset parameter isn't defined at all?

x-www-form-urlencoded forms also support _charset_ autofill. So no.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Sep 2013 20:01:25 +0200

> x-www-form-urlencoded forms also support _charset_ autofill. So no.

But they do not use the charset parameter on the content type (it's both 
not defined and irrelevant as the payload is US-ASCII anyway).

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Sep 2013 15:41:13 +0900

> not defined and irrelevant as the payload is US-ASCII anyway).

In the case of application/x-www-form-urlencoded, the _charset_ 
convention has value as it tells the server the character encoding that 
was actually used. In the case of multipart/form-data, the _charset_ 
parameter is ideally redundant.

Are there cases in the wild where there is conflicting character 
encoding information in multipart/form-data? What does server-side logic 
do? If some server side logic relies on _charset_ and some on the 
charset parameter in the content type, that means that clients have to 
send both.

Please note that server logic also just can rely on the heuristic that 
form fields come back in the same encoding that the page was sent out, 
although there are a few corner cases where that doesn't work.

Regards,   Martin.

> Best regards, Julian
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>