W3C home > Mailing lists > Public > public-webapi@w3.org > May 2007

Re: [XMLHttpRequest] Request for Last Call 2

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 08 May 2007 16:21:21 +0200
To: "Stewart Brodie" <stewart.brodie@antplc.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tr0h5pe864w2qv@id-c0020.guest-int.opera.no>

On Tue, 08 May 2007 15:18:55 +0200, Stewart Brodie  
<stewart.brodie@antplc.com> wrote:
>>> The send() event seems to have changed considerably since the previous
>>> drafts that I saw. I think that you need more explanation for the
>>> bizarre readystatechange event during step 5 of the send() algorithm
>>> since, as the note points out, the state hasn't changed.
>> This is matches what implementations do.
> Which implementations?  It doesn't match what my implementation does.

Internet Explorer, for one. Can't break significantly with that.

>> That would be in error.
> This is major change from the draft of February 27th which clearly stated
> that readystatechange events are ONLY raised when the readyState changes
> value.

In http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/#dfn-readystate it  

   2 Sent
      The user agent successfully acknowledged the request.

This same text is used in the current draft. I therefore disagree with  
your assertion that it changes behavior.

> Plus, it is extremely inconvenient to have to issue multiple events in
> succession, as it introduces a whole raft of re-entrancy issues which
> weren't present before, since assuming I send this new extra
> readystatechange event in state OPEN, the event handler may well call
> abort().

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.

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

> I think you have to
> move the setting of the "If async is true, the user agent MUST set the
> send() flag" into a new step between steps 4 and 5, and update step 6 to  
> "If the send() flag is "true" or the state is not OPEN, return from the  
> send() method call".

This would break synchronous requests.

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

>> However, it's not really clear what SENT exactly represents.
> It is not clear what "has been successfully acknowledged" means either.  
> Does it mean that the "URI accessing mechanism" of the user agent has  
> accepted
> the request for processing?
> Looking at it from a slightly different angle, what triggers the send()
> algorithm to continue executing after step 6 in the async==true case?

Nothing "triggers" it.

>> Someone suggested renaming it to REQUESTING or something, but it seems
>> some (maybe more than some?) implementations just make sure they don't
>> skip the state and basically go straight from OPEN to LOADING making  
>> sure they do SENT just before LOADING...
> Yes, that's fine - I'm pleased that that is spelt out.

I don't understand what you mean.

>> The Microsoft documentation on MSDN seems to suggest that invoking  
>> send() does indeed set the state of the object to SENT (2), but I've  
>> pointed out to them that this is not what actually happens. They  
>> haven't informed me
>> what does, though.
> Sounds to me like the person writing the documentation assumed the  
> obvious behaviour, but the implementation team broke it, then?

I don't know. I'm still waiting for a reply.

>> So you're proposing a "Conforming non-synchronous user agent" class or
>> something that throws an exception on .open() when async is false? I
>> rather not add such a thing.
> I don't see why you have to go that far.  You already have several  
> checks in the open() algorithm for badly-formed methods and URIs,  
> methods the UA
> doesn't want to support etc.

Not really.

> Having just checked, the default value for "async" has been flipped in  
> this version of the specification too - it used to default to "true",  
> but this
> one now says "false" (step 11 of the open() algorithm).

That was a mistake. Thanks for pointing it out.

>> I agree. That part will likely be updated once another specification
>> defines the security model for the web. Until that happens this
>> specification is likely to stay in CR once we get there.
> Is anybody working on such a document?

Ian Hickson has plans to integrate the web security model into the WHATWG  
Web Applications 1.0 draft. Come to think of it, he recently made some  
changes in that area, but the document itself isn't finished yet so  
referencing it will be tricky.

> Hopefully, such a specification will pull together all of these related
> issues, as there are several differing schemes in use for various things
> right now.  Off the top of my head: same-origin policy for web page
> scripting; cookies; HTTP authentication.  These are all different (I  
> think - aren't they?)
> I suggest updating the non-normative note to say that this will be  
> defined by a later specification.  Is it worth adding a brief  
> non-normative appendix describing the current rules?
> I have no idea what different browsers are using right now or whether  
> they are consistent with each other.  My current rules are: the URIs'  
> scheme and authority parts must be identical.  Putting in something like  
> that, plus a reference to RFC3986 (which is already in the references  
> list), would be
> sufficient to allow the document to stand alone until the security model
> document is drafted.

I've made an informative note about why the specification doesn't define  

Anne van Kesteren
Received on Tuesday, 8 May 2007 14:22:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC