Re: XHR: definition of same-origin

On Aug 29, 2007, at 12:52 AM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> The requests will be sent with different 'Host' http request headers
>> headers. A server configured as a virtual host could easily return
>> different content for "example.com:443" and "example.com". So it's  
>> not
>> immediately obvious that they are the same resource identifier.  
>> Indeed
>> URIs including different hostnames that resolve to the same IP  
>> address
>> are definitely NOT the same resource identifier, though once again
>> what will differ in what is sent over the wire is the 'Host' header.
>
> The URLs are equivalent, if you send different Host headers, that's  
> your
> choice, but it's neither required nor otherwise necessary. As an  
> example
> Internet Explorer 6 will not send the default port in the Host  
> header (a
> sensible choice since poorly written scripts sometimes can not cope  
> with
> that). Whatever you do though, you are not talking to different  
> hosts. A
> better case might have been http://example.com/ vs http://example.com./ 
> .

OK, looking at the various URI RFCs it seems proper to consider them  
equivalent.

>
>
>> Also, knowing the default protocol for a scheme is protocol-specific,
>> so whether an origin is considered the same would depend on whether
>> the UA is natively aware of it. Why might that matter? Consider a URI
>> scheme that can be handled only by a plugin and not the UA itself,  
>> for
>> example rtsp: can be handled by the QuickTime plugin but not directly
>> by most web browsers. If we expect a scheme's default port to have no
>> effect on same-origin checks, then a UA would have no way to  
>> correctly
>> implement the check for content where plugin data is considered to be
>> the origin.
>
> I don't think cross-scheme (or cross-port as would usually be implied
> by cross-scheme) access is currently considered same-origin. If it  
> was,
> you could use XHR to send HTTP requests to the server's SMTP service.

No, it's not, but it might be that two resources loaded over a scheme  
that cannot be directly processed by the UA may want to communicate  
with each other. I guess this couldn't apply to XHR, but it seems like  
a potential problem for other specifications using a same-origin  
policy if the results are dependent on what schemes the UA knows.

>
>
>> Any definition of a same-origin policy would have to define how to
>> determine the hostname and port. Given this, we could say that the  
>> RFC
>> registering a scheme should be referenced to determine the default
>> port, or we could include the rule for specific well-known schemes.
>> well-known schemes are where the bulk of any interoperability issues
>> will lie anyway, and for security, it's probably ok if  
>> implementations
>> err on the side of considering two URIs not to be the same origin  
>> when
>> in doubt.
>
> As far as XHR is concerned, the assumption is that the XHR executes in
> the context of some URL and attempts requests to some other URL. In  
> this
> sense I would expect a definition to say, take both URLs, strip these
> details off, and check whether the resulting URLs are equivalent as  
> de-
> fined by the relevant scheme's specification (if you don't go with the
> more traditional same-port, same-host, same-scheme definition). If you
> want cross-scheme, cross-port, or cross-host access, "same-origin"  
> would
> not be a suitable term.

It would work to specify the rules without specifying how to determine  
the origin URI of the XHR completely. However, the rule you mention  
would not work as is. For instance two textually identical data: URLs  
should not be considered to constitute a same origin for scripting  
purposes (though for XHR it doesn't matter). There may be other  
exceptions like this. Same-origin checks for scripting access are also  
affected by the document.domain property, which may supersede the URI  
check, though once again I don't think this applies to XHR.

Regards,
Maciej

Received on Wednesday, 29 August 2007 08:55:45 UTC