On Wed, 26 Sep 2007 15:51:45 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Thanks. So it say the that the origin of the Document object associated
with the Window pointer is the origin of the request. With a reference
to HTML5 to see what the origin of such a
On 10/2/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2007 14:52:17 +0200, Anne van Kesteren [EMAIL PROTECTED]
wrote:
It would be nice to get some implementation feedback on what to do about
data:, javascript: etc.
Determining the origin of data:, javascript: URIs when
On Tue, 25 Sep 2007 22:55:53 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I'm not sure offhand if baseURI is the right way to determine the
security domain. While setting document.domain does not apply, frames or
windows initially loaded with about:blank or no URI at all generally get
Anne van Kesteren wrote:
Thanks. So it say the that the origin of the Document object associated
with the Window pointer is the origin of the request. With a reference
to HTML5 to see what the origin of such a Document object actually is.
Or should it simply be the origin of the script?
Anne van Kesteren wrote:
Yes. If I get all this stuff correctly a script could be running on
bar.com using the XMLHttpRequest from another frame which is on
foo.bar.com. Depending on which definition is used it can either access
bar.com or foo.bar.com content (but not both), right?
On Wed, 26 Sep 2007 16:06:08 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Yes. If I get all this stuff correctly a script could be running on
bar.com using the XMLHttpRequest from another frame which is on
foo.bar.com. Depending on which definition is used it can
Anne van Kesteren wrote:
Hmm, actually, per HTML5 it seems that's impossible because the origin
of bar.com and foo.bar.com are not the same and therefore you can't
access any members of foo.bar.com from bar.com or vice versa.
document.domain can change this I suppose
Exactly.
but doesn't
Hallvord R. M. Steen wrote:
Note that document.domain (when set by both source and target frame)
also lets you ignore port and protocol differences, which once again
is not desirable for XHR.
I know we ignore port differences but I don't think we ignore protocol.
That's Gecko's behavior
On Sat, 22 Sep 2007 05:28:13 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Sep 21, 2007, at 3:34 AM, Anne van Kesteren wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request
is same-origin. I'm not
On Wed, 29 Aug 2007 08:51:29 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
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
Anne van Kesteren wrote:
Thanks Boris, Jonas and Maciej for your replies.
http://dev.w3.org/2006/webapi/XMLHttpRequest/Overview.html#same-origin
It would be nice to get some implementation feedback on what to do about
data:, javascript: etc.
If you're going to refer to RFC 3987, you
On Sep 25, 2007, at 5:53 AM, Anne van Kesteren wrote:
On Wed, 29 Aug 2007 08:51:29 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
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
Maciej Stachowiak wrote:
I'm not sure offhand if baseURI is the right way to determine the
security domain.
It definitely isn't, for the reasons you list.
-Boris
On Thu, 20 Sep 2007 18:40:09 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Can't we just reference RFC-3986, section 6.2.2 and 6.2.3?
I don't see those saying anything about same-origin. What am I missing?
Well, a fully normalized URI would be much easier to compare. The example
URIs
On Wed, 29 Aug 2007 05:04:24 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
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.
I think HTML5 needs to define this as my
Anne van Kesteren wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request is
same-origin.
Actually, I don't think it is. I know IE and Gecko ignore document.domain for
the existing same-origin checks...
Boris Zbarsky wrote:
Anne van Kesteren wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request
is same-origin.
Actually, I don't think it is. I know IE and Gecko ignore
document.domain for the existing
On Sep 21, 2007, at 3:34 AM, Anne van Kesteren wrote:
On Wed, 29 Aug 2007 05:04:24 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
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
On Wed, 29 Aug 2007 09:03:05 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
P.S. If we do want to specify what an origin is we should perhaps also
think about URI schemes that do not have a host and port.
Can't we just reference RFC-3986, section 6.2.2 and 6.2.3?
--
Asbjørn Ulsberg
Asbjørn Ulsberg wrote:
On Wed, 29 Aug 2007 09:03:05 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
P.S. If we do want to specify what an origin is we should perhaps
also think about URI schemes that do not have a host and port.
Can't we just reference RFC-3986, section 6.2.2 and 6.2.3?
I
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
Maciej Stachowiak wrote:
Any definition of a same-origin policy would have to define how to
determine the hostname and port.
For what it's worth, an origin in Gecko also includes the scheme. This handles
things like http-to-https access (not allowed), unknown schemes (only
same-origin with
On Aug 29, 2007, at 12:03 AM, Boris Zbarsky wrote:
Maciej Stachowiak wrote:
Any definition of a same-origin policy would have to define how to
determine the hostname and port.
For what it's worth, an origin in Gecko also includes the scheme.
This handles things like http-to-https
* 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
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
Bjoern Hoehrmann wrote:
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
For what it's worth, neither will Gecko. It will
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
On 8/28/07, Maciej Stachowiak [EMAIL PROTECTED] 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
28 matches
Mail list logo
