Implement URL.createObjectURL and URL.revokeObjectURL methods

[andreiltd]

This adds URL.createObjectURL and URL.revokeObjectURL static methods to URL as well as support for blob-scheme fetch:

• https://w3c.github.io/FileAPI/#dfn-createObjectURL
• https://fetch.spec.whatwg.org/#scheme-fetch

Some noteworthy changes include:

• move uuid generation function to a separate file so that it can be used outside crypto component,
• split main-fetch function into two fetch-https and fetch-blob functions called based on url scheme,
• implement Range content fetch for blobs,
• add integration tests for content range fetch.

Closes: #182

[andreiltd]

Hey @guybedford I was hoping I could get some early feedback about the initial commit for this work: 8d7d5c6. Specifically:

• Is it OK to get UUID implementation from Rust crate, similar to what we do with Url crate?
• the spec mentions getting origin for URL from settings object, is this something we support? Here.
• would you know where in the request-response the support for blob: schemes should be connected?

[guybedford]

Will ask @tschneidereit if he has any ideas about the UUID implementation - is there a small implementation we could inline into the codebase that avoids unnecessary code and might save some bytes? In general we want to watch binary size very carefully.

As for the request implementation it would be supporting the Blob URL everywhere we normally support a URL - so specifically fetch(blobUrl).

The worker location is the base origin to use.

[andreiltd]

Just for context, the size difference between the binary from main and this branch is 26KB. I'm not sure how much of this is due to the uuid crate.

[guybedford]

Actually I think you could just use our existing implementation of Crypto::random_uuid here and then there's no need for a third-party crate.

[andreiltd]

Actually I think you could just use our existing implementation of Crypto::random_uuid here and then there's no need for a third-party crate.

Nice, I totally missed that :)

[andreiltd]

This test checks that blob created with type: "invalid" should result in empty Content-Type header. It assumes that the blob type should be mime parsable although this assumption is not consistent with other blob tests and the spec.

As stated here: https://w3c.github.io/FileAPI/#constructorBlob

If the type member of the options argument is not the empty string, run the following sub-steps:

• Let t be the type dictionary member. If t contains any characters outside the range U+0020 to U+007E, then set t to the empty string and return from these substeps.
• Convert every character in t to ASCII lowercase.

[guybedford]

Just tested this in Chrome and what you're saying seems to be correct in that:

const b = new Blob([new Uint8Array([1,2,3])], { type: 'blah' });
const res = await fetch(URL.createObjectURL(b));
console.log(res.headers.get('content-type'));

Gives a result of blah exactly.

If that aligns with your read on this, then agreed on the implementation.

[andreiltd]

I believe this is done, although it's still depends on #181 being merged first.

[guybedford]

Just a couple of points. Having some more refactoring of shared functions into blob could be useful without introducing unnecessary dependence. Otherwise would be great to land soon.

[guybedford]

Just tested this in Chrome and what you're saying seems to be correct in that:

const b = new Blob([new Uint8Array([1,2,3])], { type: 'blah' });
const res = await fetch(URL.createObjectURL(b));
console.log(res.headers.get('content-type'));

Gives a result of blah exactly.

If that aligns with your read on this, then agreed on the implementation.

[guybedford]

I suppose this is an existing issue, but I believe fetch network errors are supposed to be DOMException::raise.

[andreiltd]

I tried changing this calls to return DOMException::raise(cx, "The owls are not what they seem", "TypeError"); but then I'm getting bunch of test failures like this:

1:   NAME:    Fetching [PUT] URL.createObjectURL(blob) is KO
1:   MESSAGE: promise_rejects_js: function "function() { throw e }" threw object "TypeError: Invalid request method for scheme fetch" ("TypeError") expected instance of function "function TypeError() {

I'm not sure if it's possible to use DOMException the way the tests expect?

[guybedford]

That might be a deeper issue with our implementation of DOMException then. See here how throw a TypeError in the spec actually means throw a TypeError which is a DOM error - https://webidl.spec.whatwg.org/#exceptiondef-typeerror.

Sorry I misread the above, throw a TypeError definitely means throw a JS typeerror - it's only when we explicitly see DOMException in the spec that we need the dom exception.

It's just I recall that network errors are DOM Exceptions, but can't find this in the spec right now.

That all said, returning a network error looks like it should return a response? https://fetch.spec.whatwg.org/#concept-network-error

[andreiltd]

That all said, returning a network error looks like it should return a response? https://fetch.spec.whatwg.org/#concept-network-error

Indeed! It looks like there is a discrepancy between the tests and the spec. E.g. see this function: https://github.com/web-platform-tests/wpt/blob/master/fetch/api/basic/scheme-blob.sub.any.js#L22

It only expects scheme-fetch to throw a TypeError on failure. I've added a network_error function that sets the response to the object according to the spec, but throws a TypeError anyway to be compliant with the tests.

[guybedford]

Would be great to get this landed asap. Ping @tschneidereit for final review.

[guybedford]

Will aim to land this one later today unless there is further feedback.