Bug 40947

Summary: REGRESSION (r57544): XMLHttpRequest POSTed multipart/form-data wrongfully gets a charset appended
Product: WebKit Reporter: Layton Duncan <layton>
Component: XMLAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, commit-queue, cshu, fishd
Priority: P1 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
proposed fix none

Description Layton Duncan 2010-06-21 14:57:28 PDT
Creating an XHR POST request while setting a "Content-Type" header value of "multipart/form-data; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV" If there is no charset specified in the header, WebKit now automatically appends a charset value to the END of the content type header before sending the request to the remote server.

Current Behaviour:
WebKit appends "; charset=UTF-8" to the end of the "Content-Type" header if not explicitly set. On "multipart/form-data" POST request, this generates an invalid request, as the charset appears after the boundary parameter:

"multipart/form-data; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV" becomes "multipart/form-data; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV; charset=UTF-8"


Desired Behaviour:
If not explicitly specified, WebKit should not append the charset parameter at the end, but inject it BEFORE the boundary parameter:

"multipart/form-data; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV" should become "multipart/form-data; charset=UTF-8; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV"

This results in a request which can be correctly parsed by the web server.
Comment 1 Alexey Proskuryakov 2010-06-22 11:56:19 PDT
My reading of XMLHttpRequest2 spec draft is that charset is never appended to Content-Type specified via setRequestHeader(), it's only corrected if it was set incorrectly.

"If a Content-Type header is set using setRequestHeader() whose value is a valid MIME type and has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of the Content-Type header to encoding."
Comment 2 Alexey Proskuryakov 2010-06-23 17:01:14 PDT
<rdar://problem/8124723>
Comment 3 Alexey Proskuryakov 2010-08-31 17:41:27 PDT
Created attachment 66149 [details]
proposed fix

The new behavior matches the spec, but doesn't quite match Firefox 3.6.8, which seem to always set a charset (but it sets it as second parameter, right after media type). I think that the spec makes more sense, and it's closer to what Safari 4 was doing.
Comment 4 Adam Barth 2010-08-31 19:24:37 PDT
Comment on attachment 66149 [details]
proposed fix

View in context: https://bugs.webkit.org/attachment.cgi?id=66149&action=prettypatch

> WebCore/xml/XMLHttpRequest.cpp:136
> +static void replaceCharsetInMediaType(String& mediaType, const String& charsetValue)
>  {
>      unsigned int pos = 0, len = 0;
Declare on separate lines?
Comment 5 WebKit Commit Bot 2010-08-31 19:47:44 PDT
Comment on attachment 66149 [details]
proposed fix

Clearing flags on attachment: 66149

Committed r66568: <http://trac.webkit.org/changeset/66568>
Comment 6 WebKit Commit Bot 2010-08-31 19:47:49 PDT
All reviewed patches have been landed.  Closing bug.