Found while writing the #375 test coverage.

Gap

handleGit sets the canonical git CORS headers (GIT_CORS_HEADERS in src/handlers/git.js:173) on its own success and 4xx paths — that was the #371 fix. But the 401/403 for an unauthorized git operation is emitted earlier, by the WAC preHandler in src/server.js (~line 540):

if (!authorized) {
  const message = needsWrite ? 'Write access required for push' : 'Read access required for clone';
  reply.header('WAC-Allow', wacAllow);
  if (!webId) {
    reply.header('WWW-Authenticate', 'Basic realm="Solid"');
  }
  return reply.code(webId ? 403 : 401).send({ error: message });
}

No Access-Control-Allow-* headers — so a browser-based git client (e.g. jss.live/git/) hitting an auth-gated repo sees a generic CORS/network error instead of the 401, which is exactly the failure mode #371 fixed for the other paths.

Fix shape

Export setGitCorsHeaders (or the GIT_CORS_HEADERS constant) from src/handlers/git.js and apply it in the preHandler's unauthorized branch (and the 402 branch above it, same reasoning). ~3 lines.

Test

test/git-handler.test.js (added in #375's PR) has a deliberately-scoped test asserting the 401 + WWW-Authenticate without the CORS assertion, with a comment pointing here. When this lands, extend that test with assertGitCors(res, ...).

Refs

• git handler: allow git-protocol header in CORS preflight responses #371 — the original git CORS fix this completes
• Add test coverage for git handler URL normalization #375 — the coverage work that surfaced the gap