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
