Re: <New: Tracking Issues in XHR that we raised>

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

Received on Monday, 23 June 2008 18:10:17 UTC