Bug 40947 – REGRESSION (r57544): XMLHttpRequest POSTed multipart/form-data wrongfully gets a charset appended

• Status: RESOLVED
• Resolution: FIXED
• Component: XML

[Layton Duncan]

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.

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

<rdar://problem/8124723>

[Alexey Proskuryakov]

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.

[Adam Barth]

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?

[WebKit Commit Bot]

Comment on attachment 66149 [details]
proposed fix

Clearing flags on attachment: 66149

Committed r66568: <http://trac.webkit.org/changeset/66568>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.