W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] security issue with XMLHttpRequest API compatibility

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 8 Apr 2009 11:23:03 +0200
To: Jonas Sicking <jonas@sicking.cc>
Message-Id: <C8C9AA29-1E07-40DF-95C1-DA78261A2AE1@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT