[pre-flight] Confine non-special-scheme 'self' matching to a registered scheme allowlist

[jonathanKingston]

Pre-flight CI run for the branch behind rust-ammonia#76. Not for merge here.

What changed

Review feedback on rust-ammonia#76 was that giving component comparison to every scheme without a default port "willfully violate[s] the spec by default", and that the client application should have to opt in. Chrome's version of that opt-in is an allowlist, so this follows Chrome's model.

The new commits add scheme_registry, an allowlist of schemes whose origin the embedder — not the URL Standard — defines:

use content_security_policy::scheme_registry;

scheme_registry::add_standard_scheme("tauri");

The 'self' component-comparison branch added by the first commit is now gated on that registry. It is empty by default, so a caller that does not opt in keeps exactly the behaviour the specification prescribes: a non-special scheme has an opaque origin and 'self' matches nothing.

How Chrome does it

Chrome registers custom schemes as standard at start-up — url::AddStandardScheme, populated from ContentClient::AddAdditionalSchemes — and gates CSP host matching on GURL::IsStandard:

// services/network/public/cpp/content_security_policy/csp_source.cc
bool SourceAllowHost(const mojom::CSPSource& source, const GURL& url) {
  return SourceAllowHost(source, url.IsStandard() ? url.GetHost() : "");
}

A URL whose scheme is not standard reports an empty host, so it matches no host-bearing source expression, 'self' included. Chrome's 'self' source is itself built from the document URL's scheme, host and port (ComputeSelfOrigin), never from an origin, which is why an opaque origin does not stand in its way there.

Deliberate departures from Chrome:

• The registry is behind an RwLock, so Chrome's url::LockSchemeRegistries step (which exists because its vectors are unsynchronised) is not needed.
• Chrome records a SchemeType per scheme; every scheme here is treated as SCHEME_WITH_HOST_AND_PORT.
• Chrome's built-in standard schemes share the same table. Here the registry holds only what the embedder registered, so is_standard_scheme is false for http, https and friends, whose origins the URL Standard already defines.

Scope

• Registration grants same-scheme, same-host, same-port matching and no upgrade allowance, so 'self' on a registered custom://example.com document still does not reach https://example.com/.
• Registering a scheme with a default port is refused rather than accepted and then quietly ignored at matching time: a tuple origin cannot tell a default port from an absent one, so 'self' matching skips those schemes either way. Registration and the matching site read the same default_port table, so they cannot drift.
• file is registerable, since it has no default port. That admits only file://server/path against a matching tuple origin — file:///a/b parses with no host at all, so component comparison cannot match it however it is registered.
• Host-source expressions are untouched. They name their own scheme, so they never needed the registry.
• A caller that never opts in pays one relaxed atomic load per 'self' source expression.

Testing

cargo test, cargo test --features=serde, cargo test --features=version-sync, cargo fmt --check, and cargo clippy --all-targets --all-features (no new warnings) all pass.

tests/self-tuple-origin.rs gains coverage for the gate itself: an unregistered scheme matches nothing however exactly its components line up, registering one scheme admits no other, and host-source expressions still work without registration.