Summary
Resolve blob: URLs (from URL.createObjectURL) through a single scheme resolver so every consumer — fetch, XMLHttpRequest, <img>/<video> src, texture loaders, … — resolves them uniformly, instead of each polyfill special-casing the scheme.
Background
#207 adds URL.createObjectURL / URL.revokeObjectURL backed by an in-memory object-URL store in the URL polyfill. Because UrlLib::UrlRequest only understands app: / file: / http(s):, the fetch and XMLHttpRequest polyfills currently intercept the blob: scheme before handing the URL to UrlLib and serve the bytes from the store themselves.
As raised in review (discussion), that doesn't scale: blob: is special-cased in fetch and again in XMLHttpRequest, and image/video src and texture loaders would each need the same branch.
Proposed direction
- Upstream (BabylonJS/UrlLib): add a registration hook for a custom scheme resolver — a callback that, given a
blob: URL, yields the bytes, content-type, and a status (found → 200, revoked/unknown → network error). UrlRequest::Open / SendAsync would dispatch to the registered resolver when the scheme matches, so StatusCode() / ResponseBuffer() / GetResponseHeader("content-type") / error reporting all work through the existing UrlRequest surface. (UrlLib has issues disabled, so this is tracked here.)
- JsRuntimeHost: register the URL polyfill's object-URL store as the
blob: resolver and remove the per-polyfill blob: branches in Polyfills/Fetch/Source/Fetch.cpp and Polyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp.
The object-URL store itself stays in the URL polyfill; only the resolution moves behind UrlLib via the registered callback.
Related
Summary
Resolve
blob:URLs (fromURL.createObjectURL) through a single scheme resolver so every consumer —fetch,XMLHttpRequest,<img>/<video>src, texture loaders, … — resolves them uniformly, instead of each polyfill special-casing the scheme.Background
#207 adds
URL.createObjectURL/URL.revokeObjectURLbacked by an in-memory object-URL store in the URL polyfill. BecauseUrlLib::UrlRequestonly understandsapp:/file:/http(s):, thefetchandXMLHttpRequestpolyfills currently intercept theblob:scheme before handing the URL to UrlLib and serve the bytes from the store themselves.As raised in review (discussion), that doesn't scale:
blob:is special-cased infetchand again inXMLHttpRequest, and image/videosrcand texture loaders would each need the same branch.Proposed direction
blob:URL, yields the bytes,content-type, and a status (found → 200, revoked/unknown → network error).UrlRequest::Open/SendAsyncwould dispatch to the registered resolver when the scheme matches, soStatusCode()/ResponseBuffer()/GetResponseHeader("content-type")/ error reporting all work through the existingUrlRequestsurface. (UrlLib has issues disabled, so this is tracked here.)blob:resolver and remove the per-polyfillblob:branches inPolyfills/Fetch/Source/Fetch.cppandPolyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp.The object-URL store itself stays in the URL polyfill; only the resolution moves behind UrlLib via the registered callback.
Related
napi_typeofforDefineClassconstructors (fixed in Add blob: URL support to URL.createObjectURL / revokeObjectURL #207).napi_add_env_cleanup_hook, which the JSC and QuickJS adapters don't implement; that gap is independent of this scheme-resolver work and keeps the store process-global for now.