Bug 99973

Created attachment 169883 [details] Patch 1 When plain text is sent using XMLHttpRequest::send method, mime type should be text/plain and encoding should be UTF-8

Comment on attachment 169883 [details] Patch 1 View in context: https://bugs.webkit.org/attachment.cgi?id=169883&action=review Thank you for splitting the work into smaller patches! This is probably the most controversial part, as you are proposing to change a longstanding part of XMLHttpRequest behavior, and something that used to be in accordance to the specification until the specification changed. A String object has no indication of type - it may carry XML just as commonly as unstructured text. Also, appending charset to posted content type is rare (and useless), so server side parsers may freak out. I think that in a case like this, there is a need to demonstrate that a proposed change is both safe and beneficial. Both seem very hard to prove - there is a lot of WebKit-only content that uses XMLHttpRequest, so comparing to other browsers would carry less weight than it normally does. As for benefit, are there any Web sites that are broken in WebKit based browsers because of this? > LayoutTests/http/tests/xmlhttprequest/post-content-type.html:4 > + <script src="../../js-test-resources/js-test-pre.js"></script> It's not necessary to build relative paths to js-test-resources in HTTP tests, you can just start from server root. > Source/WebCore/xml/XMLHttpRequest.cpp:600 > + // http://www.w3.org/TR/XMLHttpRequest/#the-send-method > + // If data is string, content type must be text/plain and encoding must be UTF-8 Please remove this comment. It just restates what the code below obviously does, and gives a link that may well be obsolete by the time someone reads it. Not even to mention that we normally look at editor's draft, not this version.

(In reply to comment #2) > I think that in a case like this, there is a need to demonstrate that a proposed change is both safe and beneficial. Both seem very hard to prove - there is a lot of WebKit-only content that uses XMLHttpRequest, so comparing to other browsers would carry less weight than it normally does. As for benefit, are there any Web sites that are broken in WebKit based browsers because of this? In that case, I think it would be safer to keep xhr::send(string) as it is now. I agree that the risk of breaking working sites is greater than the value of the proposed patch. > It's not necessary to build relative paths to js-test-resources in HTTP tests, you can just start from server root. Thanks, good to know.

Comment on attachment 169883 [details] Patch 1 OK, clearing review flag then. We can always reconsider if strong reasons to make this change are discovered.

*** Bug 108148 has been marked as a duplicate of this bug. ***

Alexey, how would you feel about making this default platform-dependent, so browsers other than Safari can opt to follow the standard?

Making core platform behaviors port specific is not advisable. It's not a matter of taste how XMLHttpRequest should work in WebKit - the behavior that's best to one port is also best to others, as pages would work uniformly in different ports.

This issue, combined with Javascript frameworks passing "" to the send method for empty bodies, causes WebKit browsers to issue invalid requests. If the Content-Type is set to XML, the server should be allowed to parse it. But the browser has no idea if it was valid XML or not, and in the case of Javascript frameworks that pass an empty String to the send method (they probably shouldn't do this, but some do), it definitely isn't valid XML. So the request is invalid, because the content type is wrong. This has manifested as an issue in Play Framework, whose default body handlers will look at the content type and attempt to parse the payload according to the content type. That issue is being tracked here: https://github.com/playframework/playframework/issues/1676

Mozilla and Blink are using text/plain;charset=UTF-8 as default content-type when sending strings. We can probably safely align here.

*** Bug 137865 has been marked as a duplicate of this bug. ***

This bug was fixed as part of bug 11049 resolution and should probably be closed.

Indeed, thank you. *** This bug has been marked as a duplicate of bug 11049 ***