Re: [xhr2] AnonXMLHttpRequest()

On Mon, May 10, 2010 at 4:05 AM, Anne van Kesteren <annevk@opera.com> wrote:

> After considering the various names for constructing an XMLHttpRequest
> object that when fetching would not expose the origin and user credentials I
> decided to go with AnonXMLHttpRequest(). It was already in the draft as a
> boolean argument for the constructor, but feedback from Maciej indicated
> that it was not good enough[1]. I also aligned the definition of user
> credentials with that of CORS:
>
>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/


Hi Anne, the current naming controversies aside, I'm curious about a few
other things:

In section 3.7.7, you say "Issue: Waiting for EcmaScript". What is this
issue? (Apologies if I have missed a previous discussion of this.)

At <http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#ref-ecmascript> you cite
"ECMAScript Language
Specification<http://www.ecma-international.org/publications/standards/Ecma-262.htm>,
Third Edition. ECMA, December 1999." The link in that citation correctly
links to the current EcmaScript spec, the Fifth Edition, December 2009. The
text in the citation should be updated.

You note twice "The Cross-Origin Resource Sharing specification [...] for
non same-origin requests." Is it clear from this document that uniform
requests to the requestor's origin qualify as "non same-origin requests"?
Even if this is precisely stated somewhere, I think the terminology is
confusing. Will readers readily understand that these cases apply to uniform
requests made to the requestor's origin?

Can one derive from this spec + CORS that a uniform request must not reveal
the response to the requestor without a "Access-Control-Allow-Origin: *"
header, even if the request is made to the requestor's origin? Perhaps
clearing up the previous confusion will address this point as well.



>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-anonxmlhttprequest
>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#user-credentials
>
>
> Mark Miller has argued that AnonXMLHttpRequest might be misleading, but
> from talking with Web developers -- asking them what they thought the effect
> on the request would be -- it seems that from
>
>  * UniformXMLHttpRequest
>  * AnonXMLHttpRequest
>  * GuestXMLHttpRequest
>  * NoContextXMLHttpRequest
>
> AnonXMLHttpRequest was the most well understood. I do not think anybody
> will be confused that you can still include some kind of identifying token
> in the entity body or a request header and that the browser will not
> magically filter it out.
>
>
> Mark Miller and Tab Atkins both argued against re-using XMLHttpRequest
> because it was not limited to XML and because it could also be used for
> HTTPS. The latter of those arguments is actually wrong. HTTPS is not a
> different protocol from HTTP, it is just a different URL scheme. (To be
> fair, browsers typically allow using XMLHttpRequest on the local file
> system.)
>
> Even so, XMLHttpRequest is the way to do requests from JavaScript and the
> new constructor will expose an object that is identical to it. In fact, it
> inherits from it and shares the prototype chain. So I decided it was a)
> better to follow convention for interfaces that inherit and b) that since it
> is very similar in nature it should be similar in name, even though the name
> is not technically sound for historical reasons.
>
>
> [1]<
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0210.html>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>


-- 
    Cheers,
    --MarkM