Add pluggable URL scheme resolver (e.g. blob:) to UrlRequest

[bkaradzic-microsoft]

What

Adds a pluggable URL scheme resolver hook to UrlRequest, so a consumer can register a resolver for a non-transport URL scheme (e.g. blob:) and have every UrlRequest-based consumer (fetch, XMLHttpRequest, image/video src, texture loaders, ...) resolve such URLs uniformly through the transport layer instead of each carrying its own branch.

UrlRequest::RegisterSchemeResolver("blob", [](const std::string& url) -> UrlSchemeResolverResult {
    // look up url in your store...
    return { /*handled*/ true, UrlStatusCode::Ok, "OK", contentType, bodyBytes };
});

How

• New public API: UrlRequest::RegisterSchemeResolver(std::string scheme, UrlSchemeResolver resolver), plus the UrlSchemeResolverResult struct and UrlSchemeResolver alias.
• When a UrlRequest is opened with a URL whose (lower-cased) scheme has a registered resolver, the platform transport is bypassed. Resolution is deferred to SendAsync() (rather than Open()) so a URL revoked between open() and send() is honored.
• A resolver that reports handled == false (e.g. a revoked blob: URL) leaves the status at 0/None and records a transport-style error, mirroring how a genuine network failure surfaces.
• The registry is process-global and mutex-guarded. All logic lives in the shared ImplBase + the shared wrapper, so every platform backend (Win32/Unix/Apple/Android) inherits it with no per-platform changes.

Testing

Builds clean with the Win32 backend (UrlLib and UrlLibTests targets). Downstream, this powers URL.createObjectURL blob: support in JsRuntimeHost — see BabylonJS/JsRuntimeHost#207 (tracked by BabylonJS/JsRuntimeHost#213), where all 216 unit tests pass with fetch/XMLHttpRequest resolving blob: through this hook.

Opened because BabylonJS/UrlLib has Issues disabled; JsRuntimeHost#207 currently pins its UrlLib dependency at this fork commit and should be repointed once this lands.

[Copilot]

Pull request overview

This PR adds a process-global, pluggable URL scheme resolver mechanism to UrlRequest, allowing non-transport schemes (e.g. blob:) to be resolved via a registered callback and served through the existing UrlRequest consumer surface (fetch/XHR/resource loaders) without per-consumer special-casing.

Changes:

• Introduces UrlSchemeResolverResult and UrlSchemeResolver, plus the public UrlRequest::RegisterSchemeResolver() API for process-global registration.
• Diverts UrlRequest::Open() when a registered scheme is detected, and performs resolver execution during SendAsync() to honor revoke-after-open scenarios.
• Adds shared-layer storage for resolver state and exposes resolved buffers via ResponseBuffer() for scheme-resolved requests.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
Source/UrlRequest_Shared.h	Hooks scheme diversion into Open(), resolves via resolver path in SendAsync(), and routes ResponseBuffer() for resolved responses.
Source/UrlRequest_Base.h	Implements the resolver registry, scheme detection, and shared-layer scheme resolution response population.
Include/UrlLib/UrlLib.h	Adds the public resolver API surface (UrlSchemeResolverResult, UrlSchemeResolver, RegisterSchemeResolver).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

LGTM. A few optional comments inline (one API-design point, two minor nits).

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

This leaves a transport request in flight across the destruction of afterUnregister, and the stated rationale doesn't hold: ~ImplBase() calls the same non-virtual Abort() as the explicit call did, so removing the explicit one doesn't change what happens to the request.

On the Apple backend it changes nothing at all. UrlRequest::Impl there has no destructor, never reads m_cancellationSource, and never calls [task cancel], so neither path stops a resumed NSURLSessionDataTask. Since nothing cancels the task, an explicit Abort() also can't be the source of the NSURLErrorCancelled (-999) attributed to it here.

The hazard is lifetime, not cancellation. SendAsync()'s completion block touches m_statusCode, m_headers, m_responseBuffer and SetError(...), so it implicitly captures a raw this, and nothing extends the Impl's lifetime (no enable_shared_from_this, no captured shared_ptr). "urllibtest-unregister:anything" yields a valid NSURL with a scheme, so the task really is resumed and NSURLSession fails it asynchronously after this scope exits, at which point the handler writes into a freed Impl. That is a likelier source of the instability the last two commits chased than an explicit abort, and it also explains why SendCompletesSynchronously() returns false here.

The lifetime gap is pre-existing rather than something this PR introduced, but this test is the first code to exercise it. Waiting for the request to settle before leaving scope, rather than abandoning it, would avoid depending on that timing. The Apple backend gap looks worth its own issue.

[bkaradzic-microsoft]

You are right on every point, and my rationale in the previous commit was wrong. I verified each claim against the source:

1. ~ImplBase() calls the same non-virtual Abort(), so removing the explicit call changed nothing about cancellation.
2. Abort() only does m_cancellationSource.cancel(), and the Apple Impl has no destructor, never reads m_cancellationSource, and never calls [task cancel] — so neither path stops a resumed NSURLSessionDataTask, and an explicit abort could not have been the source of the -999.
3. The completion handler in UrlRequest_Apple.mm writes m_statusCode, m_headers, m_responseString/m_responseBuffer and calls SetError(...) through a raw this, with nothing extending the impl's lifetime.

Your lifetime diagnosis also explains the failure far better than mine did. The -999 surfaced in a different, previously-passing test (SuccessfulLocalFileReportsNoError) as a non-empty ErrorString/ErrorSymbol with code -999 — exactly what you would expect when the abandoned task's late failure handler writes into the freed allocation that the next test's Impl was reused for. That is a use-after-free, not session cancellation, and it also explains why SendCompletesSynchronously() returned false there.

Fixed in 6d45aeb: the test now blocks until the transport request settles (SendAndWait, 60s cap) before leaving scope, and calls ADD_FAILURE() rather than silently continuing if it does not settle — so it never abandons an in-flight request or depends on that timing. The misleading comment about aborting perturbing a shared session is gone.

Agreed the backend gap deserves its own issue, and that it is pre-existing rather than introduced here. Filed as BabylonJS/JsRuntimeHost#214 (UrlLib has Issues disabled), covering the missing enable_shared_from_this/strong capture and the ignored m_cancellationSource, with a note to audit the other backends for the same pattern.