[Webkit-unassigned] [Bug 54162] New: XHR inconsistent in handling access to response attributes after an error

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=54162

           Summary: XHR inconsistent in handling access to response
                    attributes after an error
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Minor
          Priority: P4
         Component: XML
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jarred.nicholls at gmail.com


WebKit handles access to response data inconsistently as well as against w3c spec after a response error (abort, timeout, security, network) occurs (see http://dev.w3.org/2006/webapi/XMLHttpRequest-2/).

The spec says if the state is < HEADERS_RECEIVED, or the error flag is true, to return 0, null, or empty string for the following response attributes/getters:

- status
- statusText
- getResponseHeader()
- getAllResponseHeaders()

WebKit will return the status/statusText even after an error, such as an abort().  This is against the spec.
WebKit will throw a DOM exception (INVALID_STATE) when calling getResponseHeader() or getAllResponseHeaders() after an abort().  It ignores the error flag altogether.

Firefox will allow access to all the above response attributes after an abort().  This is against the spec, but they behavior consistently across all 4.
IE and Opera will throw DOM exceptions when attempting to access any of the above 4, after an abort().  This is against the spec, but again, they behave consistently across the board.

Since IE (and Opera, but mostly IE) doesn't give access to these properties, I propose we simply do the proper checks to-spec, and return the 0/null/"" values in the applicable cases of m_state < 2 or m_error == true.  Let's face it, if IE doesn't allow it, then no one's really trying to do it (sorry Firefox...)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.