Re: [XMLHttpRequest] Request for Last Call 2

"Anne van Kesteren" <annevk@opera.com> wrote:

> On Tue, 08 May 2007 13:20:21 +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.


> > I do not understand why the transition to state SENT is so complex.  In 

> > my current implementation, calling send() (in such a way that no errors 

> > occur) results in the state being set to SENT immediately and a single
> > readystatechange event being raised.
> 
> 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.

The new specification now prohibits the obvious behaviour.

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

Furthermore, the steps for send() permit that event handler to call send()
again!  This must be a bug in the algorithm, surely?  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".  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.

All these problems go away if you remove the spurious event (in the async
case, at least)

Alternatively, you could introduce a new flag that is set whilst that event
is being dispatched, and then check that flag all over the place, and
introduce another flag that is set to indicate that the send method should
just silently stop executing when the event dispatch is completed.


> > I think the above point may be answerable by providing a definition for 

> > "has been successfully acknowledged" in step 7.
> >
> > Is the purpose of the "send() flag" simply to cover the period of time
> > between the invocation of the send() method and the transition to state
> > SENT?  Why is there a period of time during which this can occur?
> 
> Because of current implementations, basically. (This hasn't changed much  
>  from last Last Call, fwiw.)

I was referring to my printout of the draft of 27th February, which is
marked as the latest revision of the document (on www.w3.org)


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



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


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


> > My implementation cannot work synchronously - and such operation is
> > highly undesirable in embedded devices anyway.  Currently, this is dealt
> > with by raising NOT_SUPPORTED_ERR in the open() call when the async
> > parameter is passed as false. I can see that the converse may be true
> > for other agents. I think that implementations should be given this
> > option.
> 
> 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.


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


> > I don't think you can leave open()'s step 10 dangling without a  
> > definition of what the same-origin policy is, particularly since the  
> > document does now link with the Window object document via which the  
> > base URI will be obtained for the purposes of comparing the two URIs.
> 
> 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?

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.


> > [...] However, I'd also like a get-out that permits user agents to
> > suspend the application of same-origin policy rules - or override the
> > policy decision - in circumstances that the UA defines.  I want the
> > trusted content in my (closed) system to be able to access anything it
> > likes.
> 
> That's already allowed. All security sensitive requirements are of the
> SHOULD-level. So if there are good reasons to ignore such a requirement
> (normally not) you can.

OK, that's fine then.


> > In the events section, what would it mean for an event on an XHR object 

> > to bubble anyway?  Bubble to where?  What about the Capture phase - what
 
> > other objects will see the event?  I suppose this is more of an issue  
> > for the DOM Events specification that here, though.
> 
> No other objects will see the event. This is just for making  
> onreadystatechange consistent with event handlers.

Good, I thought so.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Tuesday, 8 May 2007 13:18:50 UTC