Bug 16158 – Content-Type header is mishandled following a form submission

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Forms

[August Trometer]

Overview:
When a form is submitted, the Content-Type is set according to the contents and enctype of the form. 
However, that header cannot be changed to accommodate any new content based on the form submission. Other browsers (including Safari 2) negate the Content-Type header once the form is submitted.

Steps to Reproduce:
1) Create a form
2) Submit the form
3) Try to change the Content-Type header [using, for example, PHP's header('Content-Type: text/html')]
4) For simplicity's sake, redirect to another page
5) View headers on the new page
6) Note that the Content-Type header is the same as when the form was initially submitted

Actual Results:
The Content-Type header remains the same even though the form is submitted and other content is being sent to the browser.

Expected Results:
Once the form is submitted, the content type is unknown (and most likely Content-Type header should not be set according to the form enctype. Instead, the Content-Type should be wiped clean, and should be allowed to be set to another type.

Build Date & Platform:
This seems to be in effect across all versions of Safari 3 for the Mac. I've tested on Safari 3.0.4 (Consumer release version) as well as the Nightly Build. This does not seem to be an issue on Safari for Windows or on Safari on iPhone. This is not an issue on Safari 2 for the Mac. It is also not a problem with Safari 3 on OS 10.4.

Additional Information:

As a test, I submitted a form, then, after handling the form submission, I did a redirect to another URL. At that second URL, I then printed all headers. Here are my results:

Safari 3 with Normal form
Array
(
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/525.1+ (KHTML, like Gecko) Version/3.0.4 Safari/523.10
    [Cache-Control] => max-age=0
    [Accept-Language] => en-us
    [Content-Type] => application/x-www-form-urlencoded
    [Accept-Encoding] => gzip, deflate
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Connection] => keep-alive
    [Host] => formspring.com
)

Safari 3 with Multipart form
Array
(
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/525.1+ (KHTML, like Gecko) Version/3.0.4 Safari/523.10
    [Cache-Control] => max-age=0
    [Accept-Language] => en-us
    [Content-Type] => multipart/form-data; boundary=----WebKitFormBoundaryMW3p1VL35vG9NO0z
    [Accept-Encoding] => gzip, deflate
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Connection] => keep-alive
    [Host] => formspring.com
)

Safari 2 with Normal form
Array
(
    [Accept] => */*
    [Accept-Language] => en
    [Accept-Encoding] => gzip, deflate
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML...
    [Connection] => keep-alive
    [Host] => formspring.com
)

Safari 2 with Multipart form
Array
(
    [Accept] => */*
    [Accept-Language] => en
    [Accept-Encoding] => gzip, deflate
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML...
    [Connection] => keep-alive
    [Host] => formspring.com
)

Firefox 2 with Normal form
Array
(
    [Host] => formspring.com
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Accept-Language] => en-us,en;q=0.5
    [Accept-Encoding] => gzip,deflate
    [Accept-Charset] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [Keep-Alive] => 300
    [Connection] => keep-alive
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
)

Firefox 2 with Multipart form
Array
(
    [Host] => formspring.com
    [User-Agent] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Accept-Language] => en-us,en;q=0.5
    [Accept-Encoding] => gzip,deflate
    [Accept-Charset] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [Keep-Alive] => 300
    [Connection] => keep-alive
    [Referer] => http://formspring.com/forms/?427-ewYfaaC7uZ
)


The common thread I see here is that Safari 2 and Firefox do not carry over the form's Content-Type. In addition, trying to set the Content-Type [such as with PHP's header('Content-Type: text/html')] has no effect whatsoever on Safari 3's Content-Type values.

This may sound like an insignificant issue, but here's an example where it's a real problem (and how I discovered the bug).

The following form is set as enctype="multipart/form-data"

http://www.formspring.com/forms/?180283-1fguXaJVlb

When the form is submitted, it is processed, and you are then redirected to PayPal for payment. Because Safari 3's Content-Type header does not change, when PayPal gets the redirect, it reads the Content-Type as something like:

reads something like "multipart/form-data; boundary=----WebKitFormBoundaryMW3p1VL35vG9NO0z" when it

This causes PayPal to choke (I'm assuming for security reasons) and not load the "Pay Now" page that it's supposed to. Instead you get the normal login page.

Please note that Firefox, IE, Safari Windows, and Mobile Safari (iPhone) all forward to PayPal properly, and PayPal displays the desired "Pay Now" page.

Should you need further information, feel free to contact me.

[David Kilzer (:ddkilzer)]

Related to Bug 16082?

[Mark Rowe (bdash)]

This definitely sounds like bug 16082.  Thanks for the bug report.

*** This bug has been marked as a duplicate of 16082 ***