This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the File API mentions what can be done with the fragment identifier, but doesn't say anything about the query string. The File API should mention that blob: URLs should explicitly ignore the query string.
Should we at some point move all this logic to Fetch? I.e. you define how to create the URL, Fetch defines how to obtain from a blob URL? Or should Fetch provide a hook for your specification?
One "pro" of moving everything to Fetch would be to have a central place to accommodate all the (proliferating) schemes. For instance, File API defines request-response behavior for the blob: scheme, much of which is reproduced in mediastream: URLs. Then, the FileSystem API will define the filesystem: scheme, which is currently implemented in Chrome, and which the specification will standardize. If all of it is routed via Fetch, we'll have a single normative source for URL dereferencing. But I'm not *strongly* opinionated on this, and don't mind the solution of it living in separate specifications. For "LC" purposes, the File API will define blob: and maybe successor drafts (including Fetch) can deal with the protocol as it evolves (hopefully not too much).
Fixed. http://dev.w3.org/2006/webapi/FileAPI/#queryString
I don't think it needs to say anything. Specs say what to do, not what not to do; if it doesn't say to do anything with the query parameter, then nothing is done with the query parameter. The language now in the spec is confusing: it doesn't clearly mean anything, and might be interpreted to mean something wrong. For example, if you parse a blob URL with new URL(blobURL), clearly the .search attribute of the result should include the query, even if it's a blob URL. The vague language "must ignore a query string" might be interpreted to contradict that, as if the file API spec is implicitly monkey-patching the URL spec. If the intent is to ensure that appending "?foo" to a blob URL doesn't affect resolving the resource, then you probably just want to define which parts of the parsed URL are the unique identifier. With the URL spec's terminology, it looks like the identifying part is the "scheme data" (which doesn't include the query or the fragment).
Indeed, the way to fix this is to define blob URLs in terms of http://url.spec.whatwg.org/ and not in ABNF as that will not be used for parsing them anyway once http://url.spec.whatwg.org/ is implemented.
(In reply to Glenn Maynard from comment #4) > I don't think it needs to say anything. Specs say what to do, not what not > to do; if it doesn't say to do anything with the query parameter, then > nothing is done with the query parameter. > > The language now in the spec is confusing: it doesn't clearly mean anything, > and might be interpreted to mean something wrong. For example, if you parse > a blob URL with new URL(blobURL), clearly the .search attribute of the > result should include the query, even if it's a blob URL. The vague > language "must ignore a query string" might be interpreted to contradict > that, as if the file API spec is implicitly monkey-patching the URL spec. > > If the intent is to ensure that appending "?foo" to a blob URL doesn't > affect resolving the resource, then you probably just want to define which > parts of the parsed URL are the unique identifier. With the URL spec's > terminology, it looks like the identifying part is the "scheme data" (which > doesn't include the query or the fragment). I agree with this comment, and have changed the spec. to reflect this feedback.
(In reply to Anne from comment #5) > Indeed, the way to fix this is to define blob URLs in terms of > http://url.spec.whatwg.org/ and not in ABNF as that will not be used for > parsing them anyway once http://url.spec.whatwg.org/ is implemented. I think reworking this for blob: isn't useful, since it's a simple enough scheme without any real components. But url.spec.whatwg.org will be what the filesystem: scheme should be defined based on.
Arun, all URLs should be defined and created equal. There's only one URL parser after all.
(In reply to Anne from comment #8) > Arun, all URLs should be defined and created equal. There's only one URL > parser after all. Yes, but blob: is already in implementations and shipping, and I'm not clear exactly what you're suggesting. We already defer to fetch for parts of blob: URL ref culling. So: 1. Are you suggesting that url.spec.whatwg.org adds other schemes to the existing scheme list in Section 5 (that is, http://url.spec.whatwg.org/#urls)? If so, I support that, and think you may as well add some riders such as mediastream:, which ought to behave exactly like blob: as far as schemes go, since mediastream: is essentially blob: by another name. Then, when that becomes authoritative, we should deprecate what I have in the File API (which itself may be deprecated by any specs that emerge out of the ongoing discussion about Streams). 2. Or, are you suggesting I rewrite the blob: definition in terms of url.spec.whatwg.org in the File API spec.? That would have been useful feedback a bit earlier in the game. I'm not totally sure what it buys us now. Implementations are still free to use "one URL parser."
I don't think you understand. The URL Standard already defines parsing for all URLs. Relative schemes are treated specially, but for all other schemes the URL ends up as "scheme", "scheme data", "query", and "fragment". To define blob URLs in terms of this you just have to say what the "scheme data" can be (if you want to restrict the code points for producers), maybe that a conforming blob URL does not have a query and that fragment can be anything. (Reworded in specification prose of course.)
(In reply to Anne from comment #10) > I don't think you understand. The URL Standard already defines parsing for > all URLs. Relative schemes are treated specially, but for all other schemes > the URL ends up as "scheme", "scheme data", "query", and "fragment". > > To define blob URLs in terms of this you just have to say what the "scheme > data" can be (if you want to restrict the code points for producers), maybe > that a conforming blob URL does not have a query and that fragment can be > anything. (Reworded in specification prose of course.) OK, fixed per your suggestions. http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme Reopen if necessary.