Bug 21424 – charset ignored in enctype attribute of form element

• Status: RESOLVED
• Resolution: INVALID
• Component: Forms

[Andre-John Mas]

If I specify the following:

<form action="" method="post" enctype="application/x-www-form-urlencoded; charset=utf-8" accept-charset="utf-8">

I find what is actually sent to the HTTP server is:

content-type: application/x-www-form-urlencoded

The charset is stripped from the content-type.

As a comparative test I checked with Opera which is sending the charset. Additionally if I read RFC2616 section 3.7.1, there is provision for allowing the character set to be specified.

I am not sure whether to see this issue as a bug that needs fixing, or an enhancement.

[Darin Adler]

What do other browsers do?

[Andre-John Mas]

Created attachment 24147 [details]
Test case

Having run the test case under Windows XP:

Firefox 3: Content-Type: application/x-www-form-urlencoded 
IE 7: Content-Type: application/x-www-form-urlencoded 
Opera 9.5: Content-Type: application/x-www-form-urlencoded; charset=utf-8
Safari 3: Content-Type: application/x-www-form-urlencoded

Maybe I am just misinterpreting the RFC. Can anyone tell me what should be done? Maybe someone with ties to the w3c?

[Alexey Proskuryakov]

I doubt there's a better answer than "we should do what both IE and Firefox do". Also, I do not see anything in <http://www.w3.org/TR/html401/interact/forms.html> that would imply sending charset like this.

So, this just sounds like an Opera bug.

[Aryeh Gregor]

FWIW, WebKit's behavior here is correct per HTML5:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fs-enctype

Only the three literal strings "application/x-www-form-urlencoded", "multipart/form-data", and "text/plain" are allowed.  (Saw this while searching for another bug.)

[Alexey Proskuryakov]

Resolving as INVALID per all the above.