Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead
wrote:
> A new scenario just came to my attention that I thought I might
> pose to the list. Given the current same-origin restrictions on
> new Worker(), it is problematic for Worker usage by any JS
> libraries on a CDN.
>
> A site using a CDN simply provides an absolute URL reference to
> the library, and it is subsequently downloaded and executed in
> the context of the current page's domain. Relative URLs to a
> worker script will resolve according to the domain of the hosting
> page:
>
> // http://cdn.net/dowork.js which was included from http://test.com/home.htm
> var w = new Worker("lib/workers/w1.js");
> // Tries to open http://test.com/lib/workers/w1.js
>
> and absolute URLs will fail due to the cross-origin restrictions
> on the new Worker constructor:
>
> // same setup as before
> var w = new Worker("http://cdn.net/lib/workers/w1.js";);
> // Cross-origin failure from http://test.com/home.htm
>
> I looked back through the list and at the original worker proposals
> to try and discover why the same-origin restrictions is in place.
>
> The root of the issue seems to be the expectation that WorkerGlobalScope
> runs and executes everything according to its own location.URL.
> Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
> previous example, would allow http://test.com/home.htm to potentially
> modify any data associated with cdn.net's domain (like through
> Indexed DB, or XHR, etc).
>
> One way to allow the CDN scenario to work would be to provide an explicit
> way to tell a worker to run in the host context, rather than the context
> that the Worker is loaded from (which is what
[Workers] Worker same-origin and usage in JS libraries...
A new scenario just came to my attention that I thought I might
pose to the list. Given the current same-origin restrictions on
new Worker(), it is problematic for Worker usage by any JS
libraries on a CDN.
A site using a CDN simply provides an absolute URL reference to
the library, and it is subsequently downloaded and executed in
the context of the current page's domain. Relative URLs to a
worker script will resolve according to the domain of the hosting
page:
// http://cdn.net/dowork.js which was included from http://test.com/home.htm
var w = new Worker("lib/workers/w1.js");
// Tries to open http://test.com/lib/workers/w1.js
and absolute URLs will fail due to the cross-origin restrictions
on the new Worker constructor:
// same setup as before
var w = new Worker("http://cdn.net/lib/workers/w1.js";);
// Cross-origin failure from http://test.com/home.htm
I looked back through the list and at the original worker proposals
to try and discover why the same-origin restrictions is in place.
The root of the issue seems to be the expectation that WorkerGlobalScope
runs and executes everything according to its own location.URL.
Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
previous example, would allow http://test.com/home.htm to potentially
modify any data associated with cdn.net's domain (like through
Indexed DB, or XHR, etc).
One way to allow the CDN scenario to work would be to provide an explicit
way to tell a worker to run in the host context, rather than the context
that the Worker is loaded from (which is what
[Bug 15094] New: When creating a worker, it should be possible to assign some arguments to the constructor, or pass an init object like so: var worker = new Worker("someurl.js", { someData: "1234" }
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15094
Summary: When creating a worker, it should be possible to
assign some arguments to the constructor, or pass an
init object like so: var worker = new
Worker("someurl.js", { someData: "1234" }); The object
passed could be made available as the current context
(this.
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Specification: http://www.w3.org/TR/workers/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top
Comment:
When creating a worker, it should be possible to assign some arguments to the
constructor, or pass an init object like so:
var worker = new Worker("someurl.js", { someData: "1234" });
The object passed could be made available as the current context
(this.someData) or as a global variable with a predefined name.
Posted from: 84.48.203.37
User agent: Mozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; nb-no)
AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148
Safari/6533.18.5
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: Standards for Web applications on mobile devices: November 2011 updates
On Wednesday, 7 December 2011 at 00:47, Arthur Barstow wrote: > On 12/6/11 7:01 PM, ext Marcos Caceres wrote: > > I'm also concerned at use of the terms "limited" and "very limited" to > > label "current implementations" as being both subjective and relativistic - > > and it implies that attempts to implement have ceased; particularly next to > > "well deployed", "Largely deployed", "Growing", and "Getting deployed". > > Either remove that column, or present some data to which you can underpin > > each of the labels. > > > > Yes, more objective data would be good; perhaps just point to some > source like CanIUse? I guess that also raises the question about where caniuse is getting their data from? And how they keep it up to date? (might have a good answer, just have not looked at that site in a while) -- Marcos Caceres http://datadriven.com.au
Re: Standards for Web applications on mobile devices: November 2011 updates
On 12/6/11 7:01 PM, ext Marcos Caceres wrote: I'm also concerned at use of the terms "limited" and "very limited" to label "current implementations" as being both subjective and relativistic - and it implies that attempts to implement have ceased; particularly next to "well deployed", "Largely deployed", "Growing", and "Getting deployed". Either remove that column, or present some data to which you can underpin each of the labels. Yes, more objective data would be good; perhaps just point to some source like CanIUse?
Re: Standards for Web applications on mobile devices: November 2011 updates
On Tuesday, 6 December 2011 at 08:58, Dominique Hazael-Massieux wrote: > Hi all, > > I've just released a new version of “Standards for Web Applications on > Mobile” that takes into account the latest changes in the open Web > platform: > http://www.w3.org/2011/11/mobile-web-app-state.html > > Updates since August 2011 [1] includes: > * first drafts from Web RTC, of Geo API v2, Vibration API, CSS Device > Adaptation > * a bunch of last call (Device Orientation, Battery, Web Storage, Touch > Events, Web Sockets, ...) > * addition of references to accessibility materials on mobile > * mention of early work on Web Intents > > That document is extracted from the equivalent page in the W3C wiki > where contributions from others are welcomed: > http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile > > I'm planning to run another update of that document end of February. > Feedback is as always very welcomed. Although I think this document is quite informative, I again would like to raise objections about lumping app cache and widgets together for the same reasons I raised last time. However, I don't want to have that argument again: I just want to say I think it's disingenuous (perhaps make it more clear at the top of the document that the document represents mostly your personal opinion?). I'm also concerned that the text that I contributed to the document about the variety of applicability of the technologies has been removed. I'm also concerned at use of the terms "limited" and "very limited" to label "current implementations" as being both subjective and relativistic - and it implies that attempts to implement have ceased; particularly next to "well deployed", "Largely deployed", "Growing", and "Getting deployed". Either remove that column, or present some data to which you can underpin each of the labels.
Re: [cors] when a preflight goes bad
Le 5 déc. 2011 à 10:42, Benson Margulies a écrit : > For that matter, it occurs to me, even if the entire preflight is a > success, the status code will still be not found, won't it, if there > is no other OPTIONS handler for the resource? What do you mean? if you send to the server something like OPTIONS /foo HTTP/1.1 Host: www.example.com * If there is a resource defined like in this case "http://www.example.com/foo"; then the server should return a "200 OK". [1] * If the server doesn't support the OPTIONS method, then it should return a "405 Method Not Allowed" [2] But I might miss entirely your point. [1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-6.2 [2]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-7.4.6 -- Karl Dubost - http://dev.opera.com/ Developer Relations & Tools, Opera Software
Standards for Web applications on mobile devices: November 2011 updates
Hi all, I've just released a new version of “Standards for Web Applications on Mobile” that takes into account the latest changes in the open Web platform: http://www.w3.org/2011/11/mobile-web-app-state.html Updates since August 2011 [1] includes: * first drafts from Web RTC, of Geo API v2, Vibration API, CSS Device Adaptation * a bunch of last call (Device Orientation, Battery, Web Storage, Touch Events, Web Sockets, ...) * addition of references to accessibility materials on mobile * mention of early work on Web Intents That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of February. Feedback is as always very welcomed. Dom 1. http://www.w3.org/2011/08/mobile-web-app-state.html
