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 13:58:30 +0200
To: "Stewart Brodie" <stewart.brodie@antplc.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tr0aub0164w2qv@id-c0020.guest-int.opera.no>

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.

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

> 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.) However, it's not really clear what SENT  
exactly represents. 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...

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.	

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

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

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

> Finally, there's a typo in step 8 ("receieved")


Anne van Kesteren
Received on Tuesday, 8 May 2007 11:59:14 UTC

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