XMLHttpRequest: status and statusText throw DOM Exception 11 when the state is UNSENT or OPENED

• Component: XML
• Status: RESOLVED FIXED

[Jian Li]

XMLHttpRequest: getAllResponseHeaders() throws DOM Exception 11 when the state is OPENED.

Per the spec:
    When the getAllResponseHeaders() method is invoked, the user agent must run the following steps:
    If the state is UNSENT or OPENED return the empty string and terminate these steps.

Test: http://tc.labs.opera.com/apis/XMLHttpRequest/getallresponseheaders-cookies.htm

[Jian Li]

Another test for testing that the state is UNSENT:

http://tc.labs.opera.com/apis/XMLHttpRequest/xmlhttprequest-unsent.htm

[Jian Li]

The exception is also thrown when calling status, statusText, and getResponseHeader().

Per the spec:
  The status attribute must return the result of running these steps:
  If the state is UNSENT or OPENED return 0 and terminate these steps.

  The statusText attribute must return the result of running these steps:
  If the state is UNSENT or OPENED return the empty string and terminate these steps.

  When the getResponseHeader(header) is invoked, the user agent must run these steps:
  If the state is UNSENT or OPENED return null and terminate these steps.

Some more failing tests:
  http://tc.labs.opera.com/apis/XMLHttpRequest/getallresponseheaders-status.htm
  http://tc.labs.opera.com/apis/XMLHttpRequest/getresponseheader-cookies-and-more.htm
  http://tc.labs.opera.com/apis/XMLHttpRequest/xmlhttprequest-network-error.htm

[Jarred Nicholls]

Related: bug #54162

[Ryosuke Niwa]

Fixed in Blink: https://chromium.googlesource.com/chromium/blink/+/23c90460de16e04c5aba7ed942fba76cb79fdb9b

[Ryosuke Niwa]

Created attachment 216116 [details]
Merges the fix

[youenn fablet]

The patch improves conformance with W3C WPT test XMLHttpRequest/status-async.htm.
It has the expected behavior (and matches Firefox behavior) for all HTTP response codes strictly below 600.

For HTTP response codes above 600, 0 is returned as statusCode (for libsoup-based backends). On the contrary, Firefox returns the received HTTP response code.
Aligning with that behavior may require modifications to the http backends.
This should probably be handled as a separate patch.

[Alexey Proskuryakov]

Comment on attachment 216116 [details]
Merges the fix

View in context: https://bugs.webkit.org/attachment.cgi?id=216116&action=review

> Source/WebCore/ChangeLog:3
> +        XMLHttpRequest: status, statusText, getResponseHeader() and getAllResponseHeaders() throw DOM Exception 11 when the state is UNSENT or OPENED.

I don't understand what this patch does for getResponseHeader() and getAllResponseHeaders().

Please explain in ChangeLog, or rename the bug and update the ChangeLog if these are no longer part of what's being done in this bug.

Also, this change doesn't just change what's done when the state is UNSENT or OPENED - it also changes what's done in error state.

[Alexey Proskuryakov]

Please also update bug 54162 accordingly.

[Ryosuke Niwa]

(In reply to comment #8)
> Please also update bug 54162 accordingly.

I don't understand what's happening in that bug.

[Ryosuke Niwa]

Committed r161051: <http://trac.webkit.org/changeset/161051>

[Alexey Proskuryakov]

Comment on attachment 216116 [details]
Merges the fix

View in context: https://bugs.webkit.org/attachment.cgi?id=216116&action=review

> LayoutTests/ChangeLog:19
> +        * js/dom/dfg-custom-getter-throw-expected.txt:
> +        * js/dom/script-tests/dfg-custom-getter-throw-inlined.js: Fixed the test.
> +        (foo): Use responseText instead of status so that it throws when responseType is "arraybuffer".
> +        (bar): Set responseType to "arraybuffer" to cause an exception to be thrown.
> +        * js/dom/script-tests/dfg-custom-getter-throw.js: Ditto.

These tests are now crashing on bots,

http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK1%20(Tests)/r161053%20(1339)/results.html

[Ryosuke Niwa]

Reverted r161051 for reason:

Caused two DFG tests to hit assertions due to a separate bug

Committed r161058: <http://trac.webkit.org/changeset/161058>

[Ryosuke Niwa]

The patch is still valid. We just need to fix the bug 126219.

[Mark Lam]

Testing with a recent build (r165197), I don't see the JSC issues manifest anymore.  There also have been numerous changes and bug fixes in the area of exception handling and stack management since the time this bug was filed.  Those changes appear to have resolved the issue. 

I will re-land the patch and close this bug.

[Mark Lam]

The patch has been re-landed in r165229: <http://trac.webkit.org/r165229>.

[youenn fablet]

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

[youenn fablet]

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

[Anne van Kesteren]

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