- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Mon, 07 Jan 2019 19:22:49 +0000 (UTC)
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 7 January 2019 19:23:13 UTC
> What did you think about the alternate design I offered (rephrased to fix errors)? We'd move the definition of object origin into URL: return url's object's relevant global object's origin if url's object is non-null and otherwise keep the existing steps. > > Yet another alternative would be that File API returns a https://infra.spec.whatwg.org/#struct or some such wherein both the object and origin are stored. Going into File API twice for the "same thing" seems bad. Oh sorry, missed this comment. I don't think the first option works (the url's object's relevant global object is not necesarily the same as the current settings object at the time createObjectURL was called), but something like the second option could definitely work. We can just store the https://w3c.github.io/FileAPI/#blob-url-entry and extract the actual blob and origin from there. Changing the URL's object from being the blob to being a struct containing the blob would have the possibly unfortunate side effect of requiring every existing reference to that in other specs to be updated as well (which would mean at least the fetch spec, not sure if other specs refer to it). Probably wouldn't be too much work though. -- 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/pull/371#issuecomment-452050592
Received on Monday, 7 January 2019 19:23:13 UTC