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

Re: [cors] security issue with XMLHttpRequest API compatibility

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 14 Apr 2009 08:34:11 -0400
Message-Id: <6B6F2A17-E921-4176-B2A3-8AC93ED6DFFD@nokia.com>
Cc: public-webapps <public-webapps@w3.org>
To: Thomas Roessler <tlr@w3.org>, Tyler Close <tyler.close@gmail.com>, Jonas Sicking <jonas@sicking.cc>
On Apr 14, 2009, at 6:33 AM, ext Thomas Roessler wrote:

> So, to pick up on this discussion again -- I don't think we've had a
> useful conclusion whether or not the client-side JavaScript code ought
> to explicitly enable cross-site requests (as Tyler suggests, and as IE
> implements in XDR) or not.
>
> All things considered, any thoughts?

I tend to think that when adding new semantics, it generally makes  
sense to add new syntax to support those semantics and in this case  
that it would be better to err on the side of caution even if the  
mechanism chosen isn't particularly friendly to the app developer.

Yes, it would be good to get others thoughts on this, particularly  
those that have implemented CORS.

-Regards, Art Barstow


> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
> On 8 Apr 2009, at 20:07, Jonas Sicking wrote:
>
>> On Wed, Apr 8, 2009 at 2:23 AM, Thomas Roessler <tlr@w3.org> wrote:
>>> 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.
>>
>> Oh, indeed. I didn't mean to frame it as an "XHR vs XDR" thing.
>> There's certainly other ways of doing it. Tyler also proposed adding
>> an argument to the XHR constructor.
>>
>> / Jonas
>>
>>
>
>
Received on Tuesday, 14 April 2009 12:34:59 GMT

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