- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 8 Apr 2009 11:23:03 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Tyler Close <tyler.close@gmail.com>, public-webapps@w3.org
On 8 Apr 2009, at 02:29, Jonas Sicking wrote: > But it's for a limited time. In a few years hopefully all browsers > supports cross site XHR. And if you can already today follow the > advice that you should not rely on XHR not honoring your request just > because it's a cross site URI. > You are proposing a model where there's two types of XHR objects. One > where we specifically tell users that you can rely on the request > won't be sent cross site, and one where you can't. Put differently: Current web applications have a contract with the underlying browser that prevents cross-site requests from happening when XMLHttpRequest is used. That's a contract that software authors might very well rely on. The proposal within the working group (which is implemented by a number of browser vendors) is to abolish this guarantee. The approach that's implemented by IE8 (with a separate XDomainRequest) matches Tyler's requirement, and preserves the existing contract for XHR. While I can see how a single API would be a useful thing to have, I can also follow Tyler's argument; the trade-off here is indeed between following the principle of least surprise for existing Web Applications and a certain sense of simplicity for future applications. Incidentally, just framing this as "XHR vs XDR" is a bit simplistic: E.g., one could imagine a method "enableCrossSiteRequests" (or something like that) which needs to be invoked before XHR can do cross site requests.
Received on Wednesday, 8 April 2009 09:23:23 UTC