URL.RevokeBlobURL is not strict enough about blob urls

[jdm]

Spec: https://w3c.github.io/FileAPI/#dfn-revokeObjectURL

Code:

• components/script/dom/url.rs
• components/net_traits/blob_url_store.rs

Test:

• ./mach test-wpt tests/wpt/web-platform-tests/FileAPI/url/url-with-xhr.any.js
• ./mach test-wpt tests/wpt/web-platform-tests/FileAPI/url/url-with-fetch.any.js

There are a couple problems:

• we don't do any same-origin check against the blob being revoked
• the parse_blob_url helper strips off any extra parts of the URL being revoked, whereas https://w3c.github.io/FileAPI/#removeTheEntry serializes the entire url

[SiddharthaMishra]

I'd like to work on this

[Asalle]

@SiddharthaMishra are you working on this? Otherwise, i'd like to start with it.

[SiddharthaMishra]

Yeah. Sorry about delaying this, I'll finish up ASAP.

[Asalle]

@SiddharthaMishra can you assign it to yourself then?

[SiddharthaMishra]

@highfive: assign me

[highfive]

It looks like this has already been assigned to someone. I'll leave the decision to a core contributor.

[SiddharthaMishra]

@jdm, since our blob URL store has keys which are UUIDs instead of the entire urls as in the standard, does it make sense to serialize the entire URL? Should the behavior of the URL store hashmap be changed to accept the entire urls as keys?

[jdm]

@SiddharthaMishra I think the RevokeBlobURL message should be changed to accept a Url value instead of an id and an origin. The code that processes the message can parse the blob url and ignore it if there's any fragment or query string present.

[shnmorimoto]

@SiddharthaMishra Are you working on this? May I work on this?