Zhenbin Xu wrote:
It should be revised to:
"
responseText:
If the state is not DONE, raise an INVALID_STATE_ERR exception and terminate
these steps.
This doesn't seem very consistent with the other response properties
though. Seems like .getResponseHeader and .getAllResponseHeaders work
fine (without throwing) even in state HEADERS_RECEIVED and LOADING, so
it seems better to let .responseText work fine there too.
Additionally, our API has for a long time been defined such that you can
read .responseText all through the LOADING state in order to read
streaming data. This has been advertised to authors so I would expect
them to depend on that at this point and so if we started throwing here
I would expect websites to stop working.
This makes even more sense in XHR2 when we have progress events and so
the site gets notified as data comes in. (In fact, this is already the
case in firefox where you get onreadystatechange notifications for the
LOADING state every time data is received. We hope to change this to
reflect the specification and use progress events as appropriate instead
in FF3.1)
However throwing in the UNSENT and OPENED states are fine with me.
responseXML:
If the state is not at least OPENED, raise an INVALID_STATE_ERR exception and
terminate these steps.
I think we additionally need to throw in the OPENED state. Until all
headers are received there is no way to know what document, if any,
should be created so we need to either return null or throw until we're
in state HEADERS_RECEIVED.
Though it does seem scary to start throwing in more states for this
property as throwing more tends to break sites. So possibly we would
have to go with returning null in the OPENED state even though that
would be inconsistent with the other properties.
On a related note:
Can we specify exactly when .status and .statusText should throw?
Currently the spec says to throw "if not available" which seems very
implementation specific. If we say that it should throw unless the state
is at least HEADERS_RECEIVED that should make things consistent.
Note that this would be unlikely to break sites due to more throwing. As
things stand now the property is likely throw during the start of the
OPENED state, but at some point during the state stop throwing and
return a real result. So sites can't count on that happening at any
predictable time before we're in the HEADERS_RECEIVED state anyway.
/ Jonas
/ Jonas
