379858 - multipart/form-data POST of non-ascii fails to include "Content-Type: text/plain; charset=..." header inside the MIME parts of the body

Status: RESOLVED DUPLICATE of bug 116346

(Core :: DOM: Core & HTML, defect)

Description

[Robert Siemer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-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...

Comment 1

[David Nesting]

Attachment: Adds Content-Type with charset to each form-data part

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

Comment 2

[David Nesting]

See also bug 116346, which this may be a duplicate of.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yeah, this is a duplicate.  Would you mind copying the patch and relevant comment to bug 116346?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> (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.  :(