Re: [w3c/FileAPI] Support `Response` in `URL.createObjectURL` (#97)

I don't know if it makes sense to group this in with existing blob: URLs if the semantics are going to be so drastically different. Either way I'd really really like to avoid extending object URLs if at all possible, since for the vast majority of use cases they are a terrible hack.

But okay, the three proposals mentioned here:
- Creating a URL from a Response: I guess there are two parts to this?
  - The first one being able to create blob URLs for not yet available data (after all, otherwise you could just get the blob out of the response, and create a URL from that.
  - And the second part being the mentioned ability to have different response headers etc than what object URLs normally have (but if that's the semantics we're going for, than I don't think even pretending that these are object URLs is the correct choice, more on that later).
- Revoking the URL on use. This one is very tricky too. How do you define use? The specs as currently written resolve blob URLs when the URL is parsed. Would it be that parsing that revokes the URL? Or if not, and it is the fetching that revokes the URL, how do you deal with other fetches that already resolved the URL but haven't fetched it yet. Should those start to fail? But that would be inconsistent with explicit revocation which doesn't have that behavior. So this also seems like it's given these URLs very different semantics than existing object URLs.
- Limit the scope to a single realm/document: seems sort of like a reasonable thing to have, but again very different semantics than existing object URLs (although to be fair, this is how chrome implements object URLs for media sources).

So since what you're describing is very different in pretty much every way from existing object URLs does it really make sense to even have this in the same API/scheme? Would it possibly make more sense to define a new scheme for this, have API on Response (or Body, but that wouldn't have access to the headers) that generates one of these new type of URLs. And for this new type of URL we could then do the: auto-revoke on first fetch (and don't resolve until they are fetched, which should be fine since we wouldn't support manual revoke), and limit scope to the realm/document that created them?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/97#issuecomment-365038116