W3C home > Mailing lists > Public > public-webapi@w3.org > October 2007

Re: XHR: definition of same-origin

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 02 Oct 2007 16:25:18 +0200
To: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tzkqcgzl64w2qv@annevk-t60.oslo.opera.com>

On Wed, 26 Sep 2007 15:51:45 +0200, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> Anne van Kesteren wrote:
>> Thanks. So it say the that the origin of the Document object associated  
>> with the Window pointer is the origin of the request. With a reference  
>> to HTML5 to see what the origin of such a Document object actually is.  
>> Or should it simply be the origin of the script?
> Those are possibly different origins when someone is doing something  
> like:
>    window.frames[0].XMLHttpRequest
> right?  I agree that it's important to decide which origin to use in  
> this case.

I made some simple tests. If you have foo.example.org and bar.example.org  
then if http://foo.example.org/test embeds http://bar.example.org/test and  
both those files set document.domain to "example.org" and  
http://foo.example.org/test uses 'var client = new  
frames[0].XMLHttpRequest()' Internet Explorer will always do same-origin  
checks against bar.example.org. This means you can access content from  
bar.example.org using that object but you can't access foo.example.org  
content. (You can of course simply create a new object that's scoped to  
foo.example.org to do that.)

Firefox seems to have the exact same model except that in Firefox relative  
URIs are resolved against foo.example.org and not bar.example.org.

Opera resolves URIs and does same-origin checks against foo.example.org.

I will update the specification to say that URI resolving and same-origin  
checks are to be done against the Document object associated with the  
Window pointer.

Anne van Kesteren
Received on Tuesday, 2 October 2007 14:25:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC