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.

[andreiltd]

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

[andreiltd]

Sorry for the noise here. I just spent way too much time debugging problems that were result of missing break; This just helps me to remember that switch is not match.

[andreiltd]

We could probably only use uuid part of url as a key to save some cycles.