[Webkit-unassigned] [Bug 16158] New: Content-Type header is mishandled following a form submission

Tue Nov 27 10:00:48 PST 2007

http://bugs.webkit.org/show_bug.cgi?id=16158

           Summary: Content-Type header is mishandled following a form
                    submission
           Product: WebKit
           Version: 523.x (Safari 3)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Major
          Priority: P3
         Component: Forms
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: BlueGus at mac.com

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.

-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.