Closed Bug 379858 Opened 14 years ago Closed 14 years ago
multipart/form-data POST of non-ascii fails to include "Content-Type: text/plain; charset=..." header inside the MIME parts of the body
1.21 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:22.214.171.124) Gecko/20070310 Iceweasel/126.96.36.199 (Debian-188.8.131.52-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:184.108.40.206) Gecko/20070310 Iceweasel/220.127.116.11 (Debian-18.104.22.168-2) I had the urge to open a bug with a _good_ subject, as I was unable to change it on bug 289060. Please see my comment 8 on that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=289060#c8 Reproducible: Always Steps to Reproduce: 1. Create a html form with a text field and make sure the <form... element carries the attribute "enctype" set to "multipart/form-data", "method" set to "post" and "accept-charset" to e.g. "utf-8" 2. Enter data outside the ascii charset in the text field 3. Start your favorite network scanner or use something to see what the browser sends when you: 4. hit submit Actual Results: This is a snippet of the POST body representing the "name" text field. -----------------------------134580832510469477161148396949 Content-Disposition: form-data; name="name" Casos de prueba de integraciÃ³n -----------------------------134580832510469477161148396949 Expected Results: I would like to know the charset of that field, as it seems not to be ascii... -----------------------------134580832510469477161148396949 Content-Disposition: form-data; name="name" Content-Type: text/plain; charset="utf-8" Casos de prueba de integraciÃ³n -----------------------------134580832510469477161148396949 I take the liberty to mark this bug "major", as HTTP/HTML form basics are what a browser is for...
Component: General → HTML: Form Submission
Product: Firefox → Core
This is a perhaps naive attempt at adding the requisite header for each form-data part of a multipart/form-data submission. I have also created a tool at http://fastolfe.net/2007/05/06/post-charsets for testing browser behavior. The tool will treat anything ambiguous as US-ASCII, to make ambiguous cases obvious (invalid characters are replaced). A non-ASCII submission with a normal build of Firefox will see the submission garbled, while a submission with a patched Firefox works correctly. This patch does NOT address: * non-ASCII form field names * application/x-www-form-urlencoded submissions * non-ASCII form values that cannot be encoded in the chosen character encoding (The latter case causes Firefox to replace the character with an HTML entity, which IMO is also broken behavior.)
See also bug 116346, which this may be a duplicate of.
Yeah, this is a duplicate. Would you mind copying the patch and relevant comment to bug 116346?
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 116346
> (The latter case causes Firefox to replace the character with an HTML entity, > which IMO is also broken behavior.) But sadly what web servers expect... see the CVS blame for that code. :(
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.