Re: [whatwg/url] Origin of blob URLs doesn't match what implementations do (#127)

Not sure about not having the fallback in getting the origin for a blob URL. I guess it sort of makes sense from a spec point of view, but what would you return then if a URL doesn't (or no longer does) exists in the Blob URL Store? Presumably a new unique origin? It would then allow code to check if a blob url is (still) valid and not revoked by getting its origin? Not sure I like that. Also note that from the point of view of new URL(some blob url).origin it's indistinguishable if the origin is always extracted from the URL, or if it is first looked up in this map, and if not found it is gotten from the URL. Only in places where same origin checks are done with the unserialized origin (particularly for opaque origins) is there any difference.

In blink the store used to map url to origin is currently per-thread, which is problematic in that things that should work between workers and documents don't always work correctly. I think it makes the most sense for the Blob URL Store to conceptually just be completely global. Of course implementations can scope it smaller since blob urls shouldn't ever be resolved cross origin anyway, but no reason not to spec it in the simplest way? (hmm, the File API spec says non-normatively that all cross origin requests should be errors, but from the fetch spec it seems like a no-cors cross origin request would be allowed? I wonder what implementations do...)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/127#issuecomment-277162099