Re: File API: Blob URL origin
On Jun 30, 2014, at 7:13 PM, Glenn Maynard gl...@zewt.org wrote: Why would the identifier not just be the blob URL itself? Done. Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg. Blob:... won't revoke the URL, or uppercasing the hostname portion in Chrome. Using the whole URL as the identifier makes this easy to do. Subsequent attempts to dereference url must return a network error should be removed. That should already be the consequence of unregistering the URL, so this is a redundant requiremen Done: http://dev.w3.org/2006/webapi/FileAPI/ — A*
Re: File API: Blob URL origin
On Tue, Jul 1, 2014 at 5:18 PM, Arun Ranganathan a...@mozilla.com wrote: While I think mediastream URLs may have died on the vine, using the same store for filesystem URLs would be good. Yeah maybe. I thought those worked differently in that they're not really tied to objects, but rather actual files. So they would either resolve or not. We do need to have a discussion about their design at some point and make any changes to the URL parsing algorithm deemed necessary. -- http://annevankesteren.nl/
Re: File API: Blob URL origin
On Tue, Jul 1, 2014 at 1:13 AM, Glenn Maynard gl...@zewt.org wrote: Why would the identifier not just be the blob URL itself? The spec currently makes the identifier just the scheme data, which seems much more complex than it needs to be. revokeObjectURL should simply be Remove the entry from the Blob URL Store for URL. If we want to allow revoking URLs that have a fragment attached it'd still need to strip it off; Firefox does this, but Chrome doesn't. That works for me. That way we can make this a more generic store if god forbid we get more of these schemes. Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg. Blob:... won't revoke the URL, or uppercasing the hostname portion in Chrome. Using the whole URL as the identifier makes this easy to do. Ew, but okay I guess. Subsequent attempts to dereference url must return a network error should be removed. That should already be the consequence of unregistering the URL, so this is a redundant requirement. Agreed. -- http://annevankesteren.nl/
Re: File API: Blob URL origin
On Jun 30, 2014, at 7:13 PM, Glenn Maynard gl...@zewt.org wrote: Why would the identifier not just be the blob URL itself? The spec currently makes the identifier just the scheme data, which seems much more complex than it needs to be. revokeObjectURL should simply be Remove the entry from the Blob URL Store for URL. If we want to allow revoking URLs that have a fragment attached it'd still need to strip it off; Firefox does this, but Chrome doesn’t. There’s no good reason not to do this. The scheme data identifier is a hold-over from the “only UUID” model that Fx has right now (the original intent was to have a table full of UUIDs and blob references). I’m happy to change to this model. Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg. Blob:... won't revoke the URL, or uppercasing the hostname portion in Chrome. Using the whole URL as the identifier makes this easy to do. Subsequent attempts to dereference url must return a network error should be removed. That should already be the consequence of unregistering the URL, so this is a redundant requirement. OK, this is a good nit too. — A*
Re: File API: Blob URL origin
On Jul 1, 2014, at 2:32 AM, Anne van Kesteren ann...@annevk.nl wrote: That works for me. That way we can make this a more generic store if god forbid we get more of these schemes. While I think mediastream URLs may have died on the vine, using the same store for filesystem URLs would be good. — A*
Re: File API: Blob URL origin
On Jun 28, 2014, at 4:42 AM, Anne van Kesteren ann...@annevk.nl wrote: I now defined the origin for blob URLs: http://url.spec.whatwg.org/#concept-url-origin Sorry for the delay. Still need to work out the correct Fetch integration. Thanks :) Removed origin extraction from FIle API, but added identifier extraction (based on the same model — that is, running the basic URL parser). This makes adding entires to the Blob URL Store clearer. I think the Blob pieces for Fetch are in place now. http://dev.w3.org/2006/webapi/FileAPI — A*
Re: File API: Blob URL origin
On Mon, Jun 30, 2014 at 8:45 PM, Arun Ranganathan a...@mozilla.com wrote: Removed origin extraction from FIle API, but added identifier extraction (based on the same model — that is, running the basic URL parser). This makes adding entires to the Blob URL Store clearer. I don't really understand this. Entries should be added when a blob URL is created. And should be checked/removed when a blob URL is used (through parsing it in the URL parser, as defined by the URL parser). There should be no need for such a definition in the File API specification. -- http://annevankesteren.nl/
Re: File API: Blob URL origin
On Jun 30, 2014, at 4:20 PM, Anne van Kesteren ann...@annevk.nl wrote: I don't really understand this. Entries should be added when a blob URL is created. They are! That is, at the time the method URL.createObjectURL(blob) is called on blob, that method adds an entry to the Blob URL Store: http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry I’ve only defined identifier extraction for use with adding an entry. Is that wrong? And should be checked/removed when a blob URL is used (through parsing it in the URL parser, as defined by the URL parser). Yes, this is when URL parser *checks* the Blob URL Store, *after* entries have either been added or are not present (which generates a network error). There should be no need for such a definition in the File API specification. Since adding scheme data as an identifer to the Blob URL Store is the requirement, we only use the basic URL parser to get the scheme data from a generated URL to add to the Blob URL Store. — A*
Re: File API: Blob URL origin
On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com wrote: They are! That is, at the time the method URL.createObjectURL(blob) is called on blob, that method adds an entry to the Blob URL Store: http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry I’ve only defined identifier extraction for use with adding an entry. Is that wrong? It seems like you could define identifier creation, use that, use the return value to add an entry, and then return blob: + the return value. Creating a URL first and then parsing it again to extract something seems needlessly complicated. -- http://annevankesteren.nl/
Re: File API: Blob URL origin
On Jun 30, 2014, at 4:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com wrote: They are! That is, at the time the method URL.createObjectURL(blob) is called on blob, that method adds an entry to the Blob URL Store: http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry I’ve only defined identifier extraction for use with adding an entry. Is that wrong? It seems like you could define identifier creation, use that, use the return value to add an entry, and then return blob: + the return value. Creating a URL first and then parsing it again to extract something seems needlessly complicated. Well, the best way to define URL.revokeObjectURL(blobURL) seemed to be in terms of parsing to extract identifier (scheme data) and then delete the entry corresponding to identifier. But you’re absolutely right that URL.create* methods shouldn’t have a dependency on the basic URL parser, and so I’ve redefined those methods along the lines you say above (namely, defining identifier creation, and then Blob URL creation). That’s http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking in today’s editor’s draft. (So *now* maybe the path is clear for Fetch with Blobs.) — A*
Re: File API: Blob URL origin
On Mon, Jun 30, 2014 at 3:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com wrote: They are! That is, at the time the method URL.createObjectURL(blob) is called on blob, that method adds an entry to the Blob URL Store: http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry I’ve only defined identifier extraction for use with adding an entry. Is that wrong? It seems like you could define identifier creation, use that, use the return value to add an entry, and then return blob: + the return value. Creating a URL first and then parsing it again to extract something seems needlessly complicated. Why would the identifier not just be the blob URL itself? The spec currently makes the identifier just the scheme data, which seems much more complex than it needs to be. revokeObjectURL should simply be Remove the entry from the Blob URL Store for URL. If we want to allow revoking URLs that have a fragment attached it'd still need to strip it off; Firefox does this, but Chrome doesn't. Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg. Blob:... won't revoke the URL, or uppercasing the hostname portion in Chrome. Using the whole URL as the identifier makes this easy to do. Subsequent attempts to dereference url must return a network error should be removed. That should already be the consequence of unregistering the URL, so this is a redundant requirement. -- Glenn Maynard
File API: Blob URL origin
I now defined the origin for blob URLs: http://url.spec.whatwg.org/#concept-url-origin Sorry for the delay. Still need to work out the correct Fetch integration. -- http://annevankesteren.nl/
