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