Implement Blob URLs

[Ms2ger]

This is not an easy bug.

This will need integration with the URL parser.

[jdm]

Please note, this is part of a GSoC project and anyone who wants to work on this should talk to me before doing anything.

[bpowers]

hi @jdm, did this end up as part of an accepted GSoC project?

[jdm]

It did!

[izgzhen]

Just about to file an issue and found this one :D. Can someone help me to label it as assigned?

And some other related info:

• Spec: https://w3c.github.io/FileAPI/#url
• GSoC project home: https://github.com/izgzhen/gsoc-file-support, issue #10778 and issue #11131
• Ping the mentor @Manishearth

[izgzhen]

I found a problem regarding the implementation: https://w3c.github.io/FileAPI/#requestResponseModel. Here it mentions the model of "request". However, first it sounds a pretty counterintuitive thing to think about how to handle request in a browser; second, as I observed, in current implementation we will somehow intercept the LoadData message in resource_thread.rs's CoreResourceManager::load based on the url scheme and dispatch to some special loaders like about_loader and file_loader.

I am proposing to handle blob: in a similar way, however, we still don't fix the GET method problem (as specified in the spec). That is to say, our model is more like somehow internalize the "request" (which has headers, method as protocol says) into a "load" one.

[Manishearth]

somehow intercept the

Well, there's already a switch on a scheme in both http_loader and fetch, we just add an entry to that. It's possible to filter on GET, and I think XHR does this for us anyway.

[izgzhen]

Some experimental code:

https://github.com/izgzhen/servo/tree/blob-loader and https://github.com/izgzhen/servo/tree/url-interface-mock (the latest commit)

Some problems:

1. Where to put Blob URL Store? Currently I prefer to manage it under CoreResourceManager, and accessible through message interface from script thread.
2. And the above question will determine how loader will communicate with the Blob Store. Since the loader is called directly in core_resource_thread, so we can directly call it with load requests if we choose the example impl above.
3. URL origin check (currently I unicode_serialization the origin and do a simple comparison, I thought we have already better checking logics for this somewhere but I have not yet try to find it for now).

And finally the GET method problem, I inspected some dispatch on scheme code (in http_loader etc.), but not yet found anything particular interesting. Will track more in coming days.

[jdm]

I think @Manishearth meant switching on the scheme in resource_thread.rs, not http_loader.rs.

[Manishearth]

Yeah, basically.

Where to put Blob URL Store? Currently I prefer to manage it under CoreResourceManager,

CRM seems fine for now. FileManager is also okay with me

and accessible through message interface from script thread.

Does script ever need to directly fetch a blob URI? I thought we'd only have to think about HTTP and XHR loads on blob: uris, and switching in resource_thread will fix that (for XHR, you can add a similar switch in fetch, this is already specced)

so we can directly call it with load requests if we choose the example impl above.

yep. might need to be spawned in a temporary thread or loaded in the file manager thread event loop to avoid the resource task getting clogged, since there's an IPC copy involved.

URL origin check (currently I unicode_serialization the origin and do a simple comparison,

Fetch currently checks if o.ascii_serialization() is equal. XHR does the same with "as_str". I'm not sure why a simple PartialEq check on the url::Origin won't work, though.

[Manishearth]

It depends which of these two you need. https://html.spec.whatwg.org/multipage/browsers.html#same-origin . "same origin-domain" is something you'd have to implement manually.

[Manishearth]

We should really start using typed origins everywhere

[izgzhen]

I think it would be convenient to implement the same-origin check inside Origin. Also, derive serialize/deserialize for it. (Oddly url doesn't derive it now, and does't use #[derive(Ser...)] feature either)

[Manishearth]

the same-origin check is already inside Origin 😄

[Manishearth]

Why are we using strings at all though? You can obtain typed origins from typed URLs, and we have typed URLs.

[izgzhen]

Does script ever need to directly fetch a blob URI?

No, the communication between script thread and store the creation and revocation api.

[Manishearth]

Well, the file thread will handle creation. We only need a revocation message.

[izgzhen]

Check just by urlA.origin() == urlB.origin()?! It looks more like structural equivalence to me (though it looks like that the spec version "same-origin" is a structural one in a typed, or normalized context).

And for the "creation", it is to create a URL from existing Blob, so it looks like not really related to current file manager thread (although put the store under its management would leverage clogging problem you mentioned).

[Manishearth]

same-origin is structural 😄 .

Well, the existing blob is probably in the file manager thread anyway. But yeah, that depends on your caching strategy, and which in-memory data goes where. The file manager thread will be creating some blob URIs at any rate.