On Tue, 08 May 2007 15:18:55 +0200, Stewart Brodie
<[EMAIL PROTECTED]> 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
says:
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
it.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
