🚧 DRAFT — not ready for review. This PR was opened by @jeswr's AI coding agent and is intentionally in draft so that @jeswr can review it first, before it is submitted for CommunitySolidServer maintainer review. Please hold off reviewing until it's marked ready.

Problem

A single authenticated GET/HEAD resolves the target's effective .acl more than once, even though the effective ACL is identical for every resolution within the request. The resolution is expensive: an existence walk up the container hierarchy (WebAclReader.getAclRecursive → ResourceSet.hasResource) plus a read and parse of the ACL document (ResourceStore.getRepresentation → readableToQuads).

The reader is invoked three times per authenticated GET:

1. AuthorizingHttpHandler — the authorization decision, with (credentials, requestedModes).
2. WacAllowHttpHandler — the WAC-Allow user-permission pass, with the same (credentials, requestedModes).
3. WacAllowHttpHandler — the WAC-Allow public-permission pass, with (credentials: {}, requestedModes).

The CachedHandler in front of the PermissionReader is keyed by the [credentials, requestedModes] object pair. Because ModesExtractor is itself cached on the operation, passes (1) and (2) share the same (credentials, requestedModes) objects and already hit that cache. But pass (3) builds a fresh {} credentials literal on every request, so it is always a cache miss — and re-reads + re-parses the same ACL.

Measured .acl read counts on current upstream main (WAC enabled)

I instrumented ResourceStore.getRepresentation (the ACL read+parse) and ResourceSet.hasResource (the existence walk) and drove real requests through the full AuthorizingHttpHandler → WacAllowHttpHandler chain (with the real CachedHandler/WebAclReader/PermissionBasedAuthorizer):

So on current main the redundant work is one extra full ACL read + parse + existence walk per authenticated GET — the surviving duplicate is the WAC-Allow public pass. (Passes (1) and (2) are already deduplicated by the existing CachedHandler; the unauthenticated case reuses the user result and PUT skips WacAllowHttpHandler entirely.)

Fix

Memoize the credential-independent part of ACL resolution — the effective-ACL existence walk and the read + parse of the relevant authorization statements (getAclMatches + findAuthorizationStatements) — for the duration of a single request, inside WebAclReader. Each call still evaluates its own (credentials) question (findPermissions) against the shared parsed ACL, so the granted permissions are unchanged — only the redundant read/parse/walk is avoided.

Measured after the fix

The WAC-Allow public pass now reuses the parsed ACL from the authorization/user pass. Output WAC-Allow (user=…, public=…) is byte-identical before and after.

Why this is WAC-safe

This is security-critical, so the memoization is deliberately conservative:

• Request-scoped, by construction. The cache is a WeakMap keyed by the requestedModes AccessMap object. ModesExtractor produces that object exactly once per request (it is itself a CachedHandler on the operation) and shares it across all three passes above. A different request always carries a different AccessMap object, so it cannot hit an earlier request's entry, and once a request's AccessMap is unreachable the WeakMap entry becomes eligible for GC. It can never serve a stale ACL to a later request. This mirrors the request-scoping already used by CachedResourceSet (a WeakMap keyed by the ResourceIdentifier object).
• No authorization-decision change. Only the credential-independent resolution is shared; findPermissions/determinePermissions still run per call against the shared, read-only parsed quad store, so the computed PermissionMap (and hence the allow/deny decision and the WAC-Allow header) is identical. This is backed by the unchanged WebAclReader, WacAllowHttpHandler, AuthorizingHttpHandler, PermissionBasedAuthorizer unit suites and the full LdpHandlerWithAuth + PermissionTable integration suites (426 end-to-end WAC cases) all passing unchanged.
• Failures are not memoized. If the ACL read throws, the in-flight entry is removed before rethrowing, so a transient error is never cached for a later pass or request.
• No new cross-request state, no config change, no signature change — keeps the server's stateless-core property and is non-breaking.

Tests

Added a regression describe block to WebAclReader.test.ts:

• resolves the effective ACL once when reused for different credentials — calls handle() with the user credentials and then the empty ({}, public) credentials, sharing the same requestedModes object (the within-request pattern), and asserts getRepresentation + hasResource are each called once while both permission results stay correct. This test fails on main (Received number of calls: 2).
• re-resolves the effective ACL for a different request (no stale cache) — a second request with a fresh requestedModes object re-reads the ACL (asserts 2 reads), guarding the request-scoping / no-stale-serve property.
• does not memoize a failed ACL read — a failing read is not cached; the retry re-reads.

./src stays at 100% coverage.

— 🤖 PSS agent — @jeswr's coding agent for prod-solid-server / the Solid app + Pod-Manager suite. Opened in draft for @jeswr's review.