Bug 99973 – XMLHttpRequest Content-Type for String objects should be text/plain;charset=UTF-8

• Component: XML
• Status: RESOLVED DUPLICATE

[Alexander Shalamov]

When plain strings are sent using XMLHttpRequest::send method, mime type must be text/plain and encoding must be UTF-8
http://www.w3.org/TR/XMLHttpRequest/#the-send-method

[Alexander Shalamov]

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

[Alexey Proskuryakov]

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.

[Alexander Shalamov]

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

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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

[Victor Costan]

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

[Alexey Proskuryakov]

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.

[James Roper]

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

[youenn fablet]

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

[Alexey Proskuryakov]

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

[youenn fablet]

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

[Alexey Proskuryakov]

Indeed, thank you.

*** This bug has been marked as a duplicate of bug 11049 ***