On Wed, 27 May 2009, Dmitry Titov wrote:
>
> I have a question about URL origin check for Workers: the spec, in
> 4.8.2, mandates a check for the Worker URL to be the 'same origin' with
> the parent document's URL. At the same time, 4.2 says the origin of the
> worker is derived later from the U
I was wrong: CONST values and conditional compilation variables land as
properties of the window, which means they are unavailable to other scripts
only if the defining script is external and deferred.
Still, I do not think this behavior is mandatory for run-time; there may be
symbols that are hand
On Fri, May 29, 2009 at 12:27 PM, Kristof Zelechovski
wrote:
> Inserting a SCRIPT element is not equivalent to a server-side include. It
> is more like linking to an object file. In particular, substitution macros
> (e.g. CONST in BASIC) in one script do not apply other scripts (all scripts
> pr
Inserting a SCRIPT element is not equivalent to a server-side include. It
is more like linking to an object file. In particular, substitution macros
(e.g. CONST in BASIC) in one script do not apply other scripts (all scripts
present have already been parsed, and applying them to future scripts wo
On Thu, May 28, 2009 at 9:50 AM, Drew Wilson wrote:
>
>
> On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking wrote:
>>
>> On Wed, May 27, 2009 at 6:15 PM, Drew Wilson wrote:
>> > Along the same lines, I'm wondering why we require a same-domain check
>> > for
>> > initial worker URLs, but not for scr
On Thu, May 28, 2009 at 12:05 PM, Dmitry Titov wrote:
> Returning to the the narrower original question, what should we do with
> redirects during worker loads?
> - should we abort load if any URL in the redirect chain is from different
> origin?
Yes.
> - should we only abort load if the final U
For me it feels the importScripts('foo.js') is a textual #include, while
Worker('foo.js') like a call into an enclosed component. :-)
It seems inheriting origin and base URLs from parent document may create
inconsistency for shared workers since it's unclear which origin and base
URL they should i
On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking wrote:
> On Wed, May 27, 2009 at 6:15 PM, Drew Wilson wrote:
> > Along the same lines, I'm wondering why we require a same-domain check
> for
> > initial worker URLs, but not for script imported via importScripts().
>
> This is because workers run i
On Wed, May 27, 2009 at 6:15 PM, Drew Wilson wrote:
> Along the same lines, I'm wondering why we require a same-domain check for
> initial worker URLs, but not for script imported via importScripts().
This is because workers run in a security context of the initial
worker URL. So this is the orig
On Wed, May 27, 2009 at 5:13 PM, Dmitry Titov wrote:
> Should the spec simply require the redirected, final URLs to be checked
> against parent's and reject the script if redirection results in a different
> origin?
I suspect the correct behavior is to make sure every URL on the
redirect chain is
Along the same lines, I'm wondering why we require a same-domain check for
initial worker URLs, but not for script imported via importScripts(). Seems
like we ought to have workers inherit the origin of the script context that
invoked the Worker constructor, but allow the script URL passed to the
c
Hi WHATWG!
I have a question about URL origin check for Workers: the spec, in 4.8.2,
mandates a check for the Worker URL to be the 'same origin' with the parent
document's URL. At the same time, 4.2 says the origin of the worker is
derived later from the URL represented by the 'location' object of
12 matches
Mail list logo
