Re: XHR: definition of same-origin

On Aug 28, 2007, at 8:25 PM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> The XHR spec doesn't define same-origin. We had a webkit bug filed
>> differently where we apparently interpreted same-origin differently
>> than IE or Firefox: <http://bugs.webkit.org/show_bug.cgi?id=15100>
>>
>> In particular, we would not consider https://example.com:443/ to be
>> the same origin as https://example.com/.
>>
>> Since this affects interoperability as well as security I would
>> suggest adding a definition, unless the spec expected to define same-
>> origin is going to happen soon.
>
> That might make sense, but I am unsure how the bug you mention is
> relevant here.

The bug just raised the issue in my mind, since it is one example  
where the comparison is not obvious.

> It seems clear to me that https://example.com:443/
> and https://example.com/ are exactly the same resource identifier,
> just like HTTPS://example.COM is the same as https://example.com/.

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.  
Anyway, it would be good to clarify this somewhere but I now think  
that the XMLHttpRequest spec may not be a workable place.

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. (Fortunately this doesn't normally come up in HTML since  
the page embedding the plugin is considered the origin, but I could  
imagine similar situations.)

> It seems to me that if we add some kind of definition, we would
> not make explicit all the scheme-specific equivalence rules, and
> as such not really clarify the matter for the specific issue you
> mention.

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.

> Could you say how you'd envision the fix to address the problem?

The current spec doesn't define "same origin" at all. Thinking about  
it more though, it seems like it would be impossible to define  
correctly without extensive detailed reference to HTML details.

Regards,
Maciej

Received on Wednesday, 29 August 2007 06:51:41 UTC