For me it feels the importScripts('foo.js') is a textual #include, while Worker('foo.js') like a call into an enclosed component. :-)<br><br><div>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 inherit from. Given that, perhaps it's better to keep the current rule that origin and base are derived from the worker's URL, so there is consistency between dedicated and shared workers.</div>
<div><br></div><div>Returning to the the narrower original question, what should we do with redirects during worker loads? </div><div>- should we abort load if any URL in the redirect chain is from different origin?<br></div>
<div>- should we only abort load if the final URL is from different origin?</div><div>- if the same site redirects between schemas (http->https, http->data etc) does this abort loading too?</div><div>- which URL is used to compute the script's origin and/or base URL in case of redirects?</div>
<div><br></div><div>The simplest solution is to just abort loading if origin deviates in any part from parent context's, and use the final URL to compute origin (should be the same) and base URLs.</div><div><br></div>
<div>I feel these should be covered in some parts of the spec.. I saw 6.4 of HTML5 spec, but it does not cover the workers...</div><div><br></div><div>Dmitry</div><div><br><div class="gmail_quote">On Thu, May 28, 2009 at 9:50 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><br><div class="gmail_quote"><div class="im">On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, May 27, 2009 at 6:15 PM, Drew Wilson <<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>> wrote:<br>
> Along the same lines, I'm wondering why we require a same-domain check for<br>
> initial worker URLs, but not for script imported via importScripts().<br>
<br>
</div>This is because workers run in a security context of the initial<br>
worker URL. So this is the origin that is used for security checks<br>
whenever the worker does something, like load data using<br>
XMLHttpRequest.</blockquote><div><br></div></div><div>I'm not quite sure why importScripts() should behave more like a <script> tag than the Worker constructor itself. There's no reason why I shouldn't be able to do Worker("<a href="http://foo.com/worker.js" target="_blank">http://foo.com/worker.js</a>") if I can do importScript("<a href="http://foo.com/worker.js" target="_blank">http://foo.com/worker.js</a>").</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
importScripts() however behave more like <script> in that they run the<br>
loaded script in the security context of the worked that loaded them.<br>
<div><br>
> Seems<br>
> like we ought to have workers inherit the origin of the script context that<br>
> invoked the Worker constructor, but allow the script URL passed to the<br>
> constructor to point at any domain.<br>
<br>
</div>That would be another solution to this problem, however some people<br>
preferred the solution that is currently in the spec.</blockquote><div><br></div></div><div>Can anyone explain the motivation? A search of the archives isn't yielding anything particularly useful - the earliest mention I could find was someone from August of last year saying that essentially the same thing: "some people thought it was not safe" with no details.</div>

</div><br>
</blockquote></div><br></div>