Re: XHR: definition of same-origin

* 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./.

>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.

>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.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 29 August 2007 07:52:25 UTC