Re: [XMLHttpRequest] Request for Last Call 2

On Tue, 08 May 2007 18:47:56 +0200, Stewart Brodie  
<stewart.brodie@antplc.com> wrote:
>> Internet Explorer, for one. Can't break significantly with that.
>
> If the purpose of the XHR specification is simply to document the  
> Internet Explorer implementation, as determined empirically, then that's
> disappointing.  Please say that this isn't so.

To my knowledge Internet Explorer does not yet support either the  
constants or the EventTarget interface on the XMLHttpRequest object. Nor  
does it support the "readystatechange" event. It is indeed true that in  
conflict of interoperability between web browsers I have mostly picked the  
Internet Explorer way of doing it as it's more likely that web content  
will rely on the behavior of Internet Explorer than that of other  
browsers. This is the reason most methods and attributes throw exceptions  
for instance.


> That's not the sentence I was commenting on.  The behaviour that has  
> changed is the issuing of this extra event, contrary to what the previous
> specification said in several (at least 3) places, including these:
>
> [...]
>
> Neither of these sentences, or anywhere else in that document, is it
> suggested that readystatechange events may be raised at arbitrary times,
> even when the state hasn't changed - quite the opposite, in fact.
>
> But since this spurious behaviour has been seen on IE, it appears that we
> are stuck with it.  What a shame.  I can't believe that scripts actually
> rely on this, do they?

I don't know. However, Firefox for instance already follows the behavior  
of Internet Explorer here.


>> The event dispatching is based on careful reverse engineering of the  
>> most popular XMLHttpRequest implementation. So scripts would break that
>> implementation if they did such things.
>
> If the Internet Explorer implementation crashes when faced with that
> scenario, then that's a poor quality implementation.

I'm not sure how you come to that conclusion...


> If I wish to copy this IE bug, then that means I would have to carry out  
> a large scale re-engineering of the current implementation.  I'm not  
> going to do that right now - I see no compelling reason to change my  
> implementation to match this specification.

That's ok. Standards can't force you :-)


>>> Furthermore, the steps for send() permit that event handler to call
>>> send() again! This must be a bug in the algorithm, surely?
>>
>> I split that step in two. Setting the send() flag now happens directly
>> after the INVALID_STATE_ERR checks.
>
> Yes, anywhere between steps 2 and 5 would do, and it makes sense to keep  
> it near the other use for the flag.  Does that happen for synchronous as  
> well as asynchronous requests?

Please see  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8  
which I'm updating "live" whenever a comment requires me to. It only  
happens for asynchronous requests as with synchronous requests you'll  
never exit the method call in time to get a conflict like this.


>> This would break synchronous requests.
>
> Yes, it would - some other solution would be required.
>
> I think you need to specify what happens if you call abort() from an  
> event listener that is currently handling one of these OPEN-during-send()
> readystatechange events.  Obviously, you need to permit it to call  
> abort(), so that the listener can cancel network activity (although I'm  
> not sure on what basis it might be making that decision, as there's no  
> properties in the object that it can read back!)

abort() already defines that. Or do you mean I should make it more clear  
that for an asynchronous send() request the algorithm can be stopped at  
any time by invocations to either open() or abort()? I think that might  
make sense.


> By the rules for the abort() call, the abort() call in this scenario will
> put the object back into UNSENT state.  Obviously, after abort(), the  
> open() becomes available again, and from there, send() too.

open() is always "available", actually.


>>> Even that is probably insufficient, come to think of it.  The event
>>> handler may do abort(), and then open() before returning, which would
>>> leave it in a valid state, but a completely different request.
>>
>> That would reset the send flag().
>
> A minor editorial point: the specification doesn't actually say that.

I now made it more explicit when the send() flag is changed.


> Please can somebody supply an explanation of the meaning of the phrase  
> "has been successfully acknowledged".  I have no idea what it means.

Defining it in much more detail than that would probably make it too  
implementation specific. I'm thinking of just requiring user agents to go  
to the SENT state and then immediately to the LOADING state once the HTTP  
headers are in. That seems to be what implementations are more or less  
doing today (I'd love details on the Internet Explorer implementation!)  
and would remove the need for the intentionally vague sentence above.

> In that case, how does step 7 ever occur?

It would occur the moment you're receiving data back from the server,  
basically.


> In asynchronous mode, the send() method finishes executing and returns to
> its caller in step 6.  Surely you
> are not mandating that the application must be multi-threaded in order to
> use XHR in async mode and that at step 6 you MUST create a new thread for
> the asynchronous request?  That would be just unimplementable for some
> platforms.

I think it would work based on callbacks. However, defining implementation  
details like that seems unwise. Especially as I might be completely wrong  
:-) I'm just defining what needs to happen, not how.


> Nothing :-)  I was simply indicating that I liked the way that  
> specification spelled out that you must go through all the states and  
> not jump from SENT to DONE, as that was one of my concerns about it when  
> I first implemented
> XHR years ago.

Ah, great, same here :-)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 10 May 2007 12:27:32 UTC