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.
What do other browsers do?
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?
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.
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.)
Resolving as INVALID per all the above.