Bug 99973 - XMLHttpRequest Content-Type for String objects should be text/plain;charset=UTF-8
Summary: XMLHttpRequest Content-Type for String objects should be text/plain;charset=U...
Status: RESOLVED DUPLICATE of bug 11049
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alexander Shalamov
URL:
Keywords:
: 108148 137865 (view as bug list)
Depends on:
Blocks: 11049
  Show dependency treegraph
 
Reported: 2012-10-22 03:02 PDT by Alexander Shalamov
Modified: 2014-10-21 09:49 PDT (History)
11 users (show)

See Also:


Attachments
Patch 1 (77.89 KB, patch)
2012-10-22 05:25 PDT, Alexander Shalamov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Shalamov 2012-10-22 03:02:43 PDT
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
Comment 1 Alexander Shalamov 2012-10-22 05:25:52 PDT
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 2 Alexey Proskuryakov 2012-10-22 10:35:06 PDT
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.
Comment 3 Alexander Shalamov 2012-10-26 05:34:32 PDT
(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 4 Alexey Proskuryakov 2012-10-26 16:08:36 PDT
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.
Comment 5 Alexey Proskuryakov 2013-01-28 22:59:26 PST
*** Bug 108148 has been marked as a duplicate of this bug. ***
Comment 6 Victor Costan 2013-01-29 11:58:41 PST
Alexey, how would you feel about making this default platform-dependent, so browsers other than Safari can opt to follow the standard?
Comment 7 Alexey Proskuryakov 2013-01-29 17:19:08 PST
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.
Comment 8 James Roper 2013-09-16 21:11:53 PDT
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
Comment 9 youenn fablet 2014-02-18 00:19:03 PST
Mozilla and Blink are using text/plain;charset=UTF-8 as default content-type when sending strings. We can probably safely align here.
Comment 10 Alexey Proskuryakov 2014-10-20 20:59:11 PDT
*** Bug 137865 has been marked as a duplicate of this bug. ***
Comment 11 youenn fablet 2014-10-21 01:30:32 PDT
This bug was fixed as part of bug 11049 resolution and should probably be closed.
Comment 12 Alexey Proskuryakov 2014-10-21 09:49:27 PDT
Indeed, thank you.

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