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
