Make workers (including service workers) work

[mitar]

Currently, all types of workers are prohibited to be used inside suborigins. I understand the complexity of supporting service workers, but I would urge that creation of web workers from pages served under suborigin should be allowed. Semantics is pretty clear there. Simply, the web worker would have the same suborigin as the host.

For us, this is important because it allows moving existing code without any modification under suborigins. Code which was previously outside suborigins able to create web workers and communicate with them, should be able to do that as well once served from the suborigin.

The workaround mentioned (using iframes outside suborigin) does not work because such web workers cannot access same local storage and other origin-bound APIs as the suborigin code can.

So I would suggest that web workers are allowed to be created from the suborigins, but other types of workers are left for the future.

cc @wh0

[mitar]

Any progress on this?

[mitar]

So I still do not understand why web workers cannot be supported. They have clear origin. Could at least those be added to this version of spec to be supported? Then it would be really easy to port existing applications to suborigins.

[annevk]

I think the main way we could make workers work is by enforcing that after they are fetched their response carries the same Sec-Suborigin header value as the page that initiated the request.

This should also work for service workers.

Furthermore, for service workers we could then specify that their entire scope will always be within the same suborigin, though we should probably flush that out a bit to make sure that makes sense, especially given #64. It seems rather tricky if service workers would be able to return resources in response to navigation that have different suborigins from themselves.

cc @jakearchibald

(Again, I don't think any of this applies to Origin Isolation. There everything should work as it does today.)

[jakearchibald]

If sub-origin identifiers weren't path-based, then for service workers I think we'd need to require that the scope was unique across the origin and all the sub origins.

When the user navigates to a URL, we need to decide which service worker to use, and we don't know anything about sub-origin at that point. Once we've identified a service worker, I guess the resulting page would be the same sub-origin as the service worker.

The sub-origin of the service worker would be the sub-origin of the client that registered it.