Equivalent issue in WebKit: https://bugs.webkit.org/show_bug.cgi?id=156125

FWIW Edge throws an "Invalid argument" exception if you append a query string to a blob URL.

Over in WebKit land, we're not convinced this is a bug.

The spec seems to make no allowance for this, and Edge arguably gets this the most correct by throwing that exception.

See my comment here: https://bugs.webkit.org/show_bug.cgi?id=156125#c3

Since Firefox is the odd-man out, and if we agree the spec agrees with WebKit/Blink/Edge, perhaps we should actually file a bug on Firefox to change.

Blob URLs are handled in storage/browser/blob, not the network stack; reassigning accordingly.

Able to reproduce the issue on Mac 10.11.3 using canary 51.0.2700.0.
This is a non-regression issues since M 30.0.1549.0  on Mac 10.11.3, Win 7 and Ubuntu 14.04.

I agree with beidson@ - blob URLs should be opaque for a variety of reasons (including future flexibility)

Where exactly does Edge throw?

This seems to be something where the File API and URL specs are in disagreement. The File API spec indeed seems to agree with the behavior in blink/webkit/edge, but also says that it is not normative about behavior related to fetching blob urls (deferring to the fetch and url specs for normative behavior). The way URL parsing is written in the URL spec (https://url.spec.whatwg.org/#url-parsing) it seems to allow for query parameters (that should be ignored) and even extra path components (it only look at the first string in the urls path).

So at least we should figure out which behavior is desired and make the various specs consistent with that behavior.

In practical terms, parameters can be appended to blob urls as # fragments, so no functionality is lost with the inability to pass them as query parameters.

I think the thinking was that ? parameters are usually interpreted by a remote agency and since there is no remote agency behind a blob url, query parameters shouldn't apply.

Needs feedback about a spec change prior to doing any work on this. Personally, I don't see a reason to change to the spec or our code but ultimately its a spec question.

Assigning to mek to resolve the spec inconsistencies. @mek feel free to move to someone else if they're better suited :)

FWIW in https://github.com/w3c/FileAPI/pull/92 I've started on clarifying blob URL behavior better, and at least for now I'm leaning towards making the chrome/webkit/edge behavior explicit, and thus making fetching blob URLs with query parameters an error. Please weigh in there if you have different opinions.

The spec was updated to make the described behavior correct (modulo whether fetching an invalid blob URL returns a 404 or triggers a network error, but that's a different bug).

 Issue 907452  has been merged into this issue.

Thanks!