Closed Bug 464848 Opened 11 years ago Closed 11 years ago

simple cross-site XHR POST goes off deep end

Categories

(Core :: DOM: Core & HTML, defect, P1)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: vlad, Assigned: sicking)

References

Details

(Keywords: fixed1.9.1)

Attachments

(2 files, 2 obsolete files)

If you do a simple XHR POST without an explicit xhr.setRequestHeader("Content-Type", "text/plain"), you go down the preflight path which is painful.  sicking has more details.
Flags: blocking1.9.1?
The reason is that we end up setting a charset parameter on the content-type. When checking for text/plain we should ignore any charset parameters, or at least ignore any that we set ourselves.
Assignee: nobody → jonas
Flags: blocking1.9.1? → blocking1.9.1+
When we set it ourselves, is it based on the charset of the page?  If so, is that enough of a reason to want to do a preflight?
Sites relying on the content-type is in itself a pretty extreme assumption that the Access-Control spec is making. That they rely on the charset sounds extremely unlikely.

Additionally, we've discussed (or might even already have tried) adding the charset when submitting <form>s which would allow the exact same thing.
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b3
Attached patch Patch to fix (obsolete) — Splinter Review
The problem wasn't in the Access-Control code at all. Turns out we're most of the time sending "application/xml" as content-type, even when sending plain strings. This rightly makes the Access-Control code go into preflight mode.

The patch makes us follow the XHR spec with regards to content-type, which means that we don't require a preflight.
Attached patch Patch -w (obsolete) — Splinter Review
Attachment #356858 - Flags: superreview?(bzbarsky)
Attachment #356858 - Flags: review?(bzbarsky)
Attached patch Patch to fixSplinter Review
Oops, those were patches for a different bug. This one's correct
Attachment #356856 - Attachment is obsolete: true
Attachment #356858 - Attachment is obsolete: true
Attachment #356858 - Flags: superreview?(bzbarsky)
Attachment #356858 - Flags: review?(bzbarsky)
Attached patch Patch -wSplinter Review
Attachment #356863 - Flags: superreview?(bzbarsky)
Attachment #356863 - Flags: review?(bzbarsky)
Comment on attachment 356863 [details] [diff] [review]
Patch -w

>+++ src.e5393cfc9dc1/content/base/src/nsXMLHttpRequest.cpp	2009-01-13 17:15:51.000000000 -0800
>+    nsCAutoString defaultContentType(NS_LITERAL_CSTRING("text/plain"));

I haven't put in the time to sort out the tests enough, but I assume you added a test for this.  ;)

>-    case nsIDataType::VTYPE_EMPTY_ARRAY:
>-    case nsIDataType::VTYPE_ARRAY:
>-      // IE6 throws error here, so we do that as well
>-      return NS_ERROR_INVALID_ARG;

And I assume a test for this too?

>-        if (NS_FAILED(rv)) {

For what it's worth, in practice NS_ExtractCharsetFromContentType never returns failure.  I'm fine with the change here, in any case.

r+sr=bzbarsky
Attachment #356863 - Flags: superreview?(bzbarsky)
Attachment #356863 - Flags: superreview+
Attachment #356863 - Flags: review?(bzbarsky)
Attachment #356863 - Flags: review+
(In reply to comment #8)
> (From update of attachment 356863 [details] [diff] [review])
> >+++ src.e5393cfc9dc1/content/base/src/nsXMLHttpRequest.cpp	2009-01-13 17:15:51.000000000 -0800
> >+    nsCAutoString defaultContentType(NS_LITERAL_CSTRING("text/plain"));
> 
> I haven't put in the time to sort out the tests enough, but I assume you added
> a test for this.  ;)

Yup, the new test_XHRSendData test tests this.

> >-    case nsIDataType::VTYPE_EMPTY_ARRAY:
> >-    case nsIDataType::VTYPE_ARRAY:
> >-      // IE6 throws error here, so we do that as well
> >-      return NS_ERROR_INVALID_ARG;
> 
> And I assume a test for this too?

Turns out our code is majorly broken for anything that isn't a string or a document. If I pass in an array or an object we fail when trying to convert to a string and end up throwing.

Fixing that will be a separate bug though, one we won't fix for 1.9.1
This was checked in
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
There are 8 mochitest fails on mozilla-1.9.1 since this bug (or bug 464954) landed, win32 only:

*** 3695 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- comment -->\r\n<out>hi</out>", expected "<!-- comment -->\n<out>hi</out>"
*** 3697 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- comment -->\r\n<out>hi</out>", expected "<!-- comment -->\n<out>hi</out>"
*** 3699 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- comment -->\r\n<out>hi</out>", expected "<!-- comment -->\n<out>hi</out>"
*** 3701 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- comment -->\r\n<out>hi</out>", expected "<!-- comment -->\n<out>hi</out>"
*** 3703 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- doc 2 -->\r\n<res>text</res>", expected "<!-- doc 2 -->\n<res>text</res>"
*** 3705 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- doc 2 -->\r\n<res>text</res>", expected "<!-- doc 2 -->\n<res>text</res>"
*** 3707 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- doc 2 -->\r\n<res>text</res>", expected "<!-- doc 2 -->\n<res>text</res>"
*** 3709 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_XHRSendData.html | Wrong body - got "<!-- doc 2 -->\r\n<res>text</res>", expected "<!-- doc 2 -->\n<res>text</res>"

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1232752728.1232758413.24642.gz

Looks like a line-ending problem.
Component: Content → DOM
QA Contact: content → general
Depends on: 503615
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.