Bug 101776

Summary:

[XHR2] XMLHttpRequest.status does not behave according to specification

Product:

WebKit

Reporter:

Chris Dumez <cdumez>

Component:

WebCore Misc.

Assignee:

Chris Dumez <cdumez>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

abarth, ap, dglazkov, d-r, eric, ggaren, haraken, japhet, laszlo.gombos, ojan, s.choi, syoichi, tkent, webkit.review.bot, youennf

Priority:

Keywords:

WebExposed

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

URL:

http://www.w3.org/TR/XMLHttpRequest2/#the-status-attribute

Attachments:

Description	Flags
Results with different browsers	none
Patch	webkit.review.bot: commit-queue-
Patch	none

Chris Dumez

Reported 2012-11-09 10:33:57 PST

According to specification, the behavior for XMLHttpRequest.status should be as follows: The status attribute must return the result of running these steps: * If the state is UNSENT or OPENED, return 0 and terminate these steps. * If the error flag is set, return 0 and terminate these steps. * Return the HTTP status code. Currently, WebKit does: * Return 0 if the state in UNSET * Throw an INVALID_STATE_ERR if state is OPENED * Return HTTP status code (even if error flag is set) Firefox and Opera both follow the spec exactly. What IE9 does: * If the state is UNSENT or OPENED, throw an exception * If the error flag is set, throw an exception * Return HTTP status code.

Attachments
Results with different browsers (3.35 KB, text/plain) 2012-11-09 10:39 PST, Chris Dumez	no flags	Details
Patch (9.95 KB, patch) 2012-11-09 11:38 PST, Chris Dumez	webkit.review.bot: commit-queue-	Details Formatted Diff Diff
Patch (35.02 KB, patch) 2012-11-09 14:25 PST, Chris Dumez	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Chris Dumez

Comment 1 2012-11-09 10:39:10 PST

Created attachment 173335 [details] Results with different browsers

Chris Dumez

Comment 2 2012-11-09 10:40:06 PST

I attached the results of LayoutTests/http/tests/xmlhttprequest/status-after-abort.html with all major browsers.

Chris Dumez

Comment 3 2012-11-09 11:38:07 PST

Created attachment 173342 [details] Patch

WebKit Review Bot

Comment 4 2012-11-09 13:40:14 PST

Comment on attachment 173342 [details] Patch Attachment 173342 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14788251 New failing tests: fast/js/dfg-custom-getter-throw.html fast/js/dfg-custom-getter-throw-inlined.html

Chris Dumez

Comment 5 2012-11-09 14:25:22 PST

Created attachment 173364 [details] Patch Update the following tests since they relied on XMLHTTPRequest.status to throw: fast/js/dfg-custom-getter-throw.html fast/js/dfg-custom-getter-throw-inlined.html

Alexey Proskuryakov

Comment 6 2012-11-09 14:27:45 PST

This changes many behaviors at once. To pick one, both IE and WebKit raise an exception in OPENED state. Why shouldn't the spec be changed to match the vast majority of browsers here? Generally, speaking, Firefox, Opera and a spec combined don't have enough weight for us to change unless there is an additional good reason to.

Anders Carlsson

Comment 7 2014-02-05 11:07:34 PST

Comment on attachment 173364 [details] Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.

youenn fablet

Comment 8 2014-02-10 00:55:37 PST

This bug is handled by bug 45994 last patch. Once bug 45994 is closed, this bug should probably be closed as well.

youenn fablet

Comment 9 2014-03-18 08:28:36 PDT

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

Note You need to log in before you can comment on or make changes to this bug.