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



> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, June 23, 2008 11:09 AM
> To: Zhenbin Xu
> Cc: Anne van Kesteren; Sunava Dutta; Ian Hickson; public-
> webapps@w3.org; IE8 Core AJAX SWAT Team
> Subject: 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.
>

[Zhenbin Xu] This shouldn't be a compact issue since IE throws exception
before DONE state since first release of XMLHTTP and we have not seen
compact issue from Internet sites or enterprise applications.

Streaming is a good topic that we should refine and define clear specifications,
thus it is better suited for XHR2. And like you have noted below, progress
event is a better design for streaming.




> 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.
>


[Zhenbin Xu] An empty XML document can always be created before all headers
are 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.
>

[Zhenbin Xu]  Yes throwing on more states has more possibility of breaking
sites. So I don't think it is a good direction to go.

Returning null in OPENED state would break sites that are expecting
a non-null responseXML after open() call. OTOH, If the site is already testing
for null, it will continue to work if non-null responseXML is returned. So
what I stated previously is a good specification.




>
> 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 20:51:54 UTC