Re: On starting WebWorkers with blob: URLs...

On Feb 19, 2014, at 7:09 PM, Jonas Sicking wrote:

> On Wed, Feb 19, 2014 at 3:51 PM, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
>> Seems like our specs are getting a little behind implementations. In IE11 we are finding that several new sites, notably those using WebGL content, have a dependency on starting web workers with a Blob URL. As I understand it:
>> 
>> The W3C Web Workers spec (CR stage) forbids use of the data and [implicitly] blob protocols
>> The WHATWG HTML spec (Living stage) allows data protocol, but not blob.
>> Implementations of Firefox and Chrome support blob protocols
>> 
>> 1. Seems like a spec should say this somewhere...
> 
> Agreed! It's a bit tricky since the concept of origins and thus "same
> origin" for data: and blob: is a bit unclear still. I.e. browsers
> don't behave consistently. Definitely not between each other, and
> sometimes not internally within a browser IIRC.


Well, for data: URLs what's normative might be: http://tools.ietf.org/html/rfc6454#section-4 but sadly that's not really clear (what's "host" here?).

For blob: URLs we agreed to make this pretty explicit: 
http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL

Also, Blob URL Stores apply to each unit of similar origin browing contexts, which means that URL.createObjectURL and URL.createFor essentially give URL fetch and URL parse license to operate only within the origin of the script those methods apply to; URL.revokeObjectURL only applies to that origin also.

So now, we've made it pretty explicit for Blob URLs.


>> 2. In the W3C where would we spec this? (Workers V2?)
> 
> I care less strongly about this. There's also the synchronous message
> passing API which I'd still like to see added to the workers spec.


IMHO it makes sense in Workers V2.

-- A*

Received on Wednesday, 12 March 2014 15:39:11 UTC