[Webkit-unassigned] [Bug 28970] New: content-type parameters not taken into account when building form-data

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28970

           Summary: content-type parameters not taken into account when
                    building form-data
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pmuellr at yahoo.com
                CC: timothy at hatcher.name, aroben at apple.com,
                    kmccullough at apple.com


Created an attachment (id=39062)
 --> (https://bugs.webkit.org/attachment.cgi?id=39062)
the red circles show the charset parameter on the header, and the result
interpretation as not being form data, when it actually is

In the new support for displaying form data in the resource view in the
Resources Panel, the code is currently looking for a Content-Type of
"application/x-www-form-urlencoded" to trigger the formatting of the request
data into a set of form data elements.  This isn't good enough.  In the wild,
it's been spotted that gmail sends requests with "form data" using a
Content-Type header of "application/x-www-form-urlencoded;charset=utf-8".

Two obvious things to look at:

- change the code to be more flexible in recognizing the content type by doing
a comparison after stripping the header value parameters, in this case,
"charset=utf-8".

- do we need to do some additional decoding/encoding based on that charset
value?  Seems a bit nightmarish, since it may be dependent on what text
encoding the browser is currently using also.  I've also never been clear on
how encoding of query string parameters in the URL itself works, since there's
no way to denote the charset there.

Another thing to look at is if there are other content types in use.  A search
on "application/www-form-urlencoded", for instance, yields the following:

   http://www.mail-archive.com/www-archive@w3.org/msg00187.html

Is this used in the wild?  Doesn't appear to be, but should do some additional
research.

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