How does this compare to the Cross-Site Extensions for XMLHttpRequest
standard
that is being developed by Web API and Web App Formats (and
as implemented in Firefox betas)?
The major ones, IMO:
1. XDomainRequest uses a different constructor/API to make requests
(XDomainRequest instead of XMLHttpRequest).
2. XDomainRequest does not allow any headers. The W3C/AC for XSite requests
allows headers like "Accept" and "Accept-Language" which are crucial for the
fundamental HTTP capability of content and language negotiation.
3. Completely different server side response required to validate cross-site
requests are acceptable. XDomainRequest looks for a response header of
"XDomainRequestAllowed: 1", while W3C/AC, looks for an Access-Control header
which has more fine-grained control.
4. Cookies and credentials are not sent with XDomainRequest. I believe this
is still being discussed with W3C/AC.
5. Standard HTTP REST methods (PUT and DELETE) are not supported with
XDomainRequest, but are supported with W3C/AC.
From Apple's point of view we would like to have a
unified standard in this area.
From web developer/framework developer's point of view, we would also
like a unified standard. Creating a new divergent API for cross-site
requests with XDR is certainly not the most beneficial approach for web
developers. Cross-site requests that work in all browsers (those that
implement W3C/AC and XDR) would look like:
if (window.XDomainRequest) {
var xhr = new XDomainRequest(); // IE's cross-domain request technique
}
else {
var xhr = new XMLHttpRequest(); // W3C and standards compliant browsers
cross-domain request technique
}
xhr.open("POST","http://otherdomain.com",true);
xhr.send();
And on the server, the server needs to at least set headers
"XDomainRequestAllowed: 1" and "Access-Control: allow *" for the responses
to be accessible in all browsers.
Does this seem like a clean API for devs? I think it would be much cleaner
and easier for developers if Microsoft adopted the W3C cross-site request
mechanism and worked to improve it, rather than creating a different API.
snipping from Chris's email:
The short version is, as Sunava discusses in the summary of this mail,
that x-domain XHR (and Flash’s approach, et al) is subject to specific
x-domain injection attacks because of its persistent-allow design.
I understand that MS has security concerns, but rewriting the API is not
necessary to address these concerns. If there are aspects of the W3C/AC
proposal that MS doesn't like, I am sure discussion and feedback would be
welcome. Even minor deviations from W3C/AC proposal to satisfy the Microsoft
security concerns (such as stripping cookies, and requiring the
Access-Control header on every response) would be vastly better than using a
completely different API. I think the web development community would
appreciate standards convergence much more than multiple APIs. Having
multiple APIs increases complexity which increases the vector of possible
attacks.
Specifically, any request sent by XDR could also be emitted by a
properly coded HTML FORM object. Hence, any “non-participating”
web server put at risk by XDR is also at risk from simple HTML.
This is not true. I could send a POST request with XDR with a body of any
string. This is not possible in a form. A form strictly encodes everything
in URL encoded format. A server that expects that a body with pure JSON
would only come from a safe client (since this is not possible with a form),
would be in for a surprise with XDR. W3C/AC protects against this
vulnerability. IMO, this is a vulnerability and XDR may actually be
less secure than W3C/AC (and certainly less funtional).
Thanks,
Kris
