Health endpoint returns 401 for trailing-slash variant /health/ (public probe marked unhealthy)

[jonbaldie]

Property

The /health endpoint is documented (openapi.yaml lines 17-36) as public — security: [], no authentication required — and returns 200. A health/liveness probe that reaches a trailing-slash variant (/health/) must receive the same public 200 (or at least not an authentication challenge). Load balancers, k8s liveness/readiness probes, and some HTTP clients normalize or append trailing slashes.

Counterexample

QUEUE_API_TOKEN=tok HOST=127.0.0.1 PORT=3992 deno run --allow-net --allow-env main.ts &
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3992/health     # 200  ✓
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3992/health/    # 401  ✗ — public endpoint returns "Unauthorized"
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3992/health//   # 401  ✗

A health check configured with a trailing slash gets 401 Unauthorized, so the probe marks a healthy service as down.

Root cause

The auth bypass in src/middleware.ts uses the same exact-match URLPattern as the router:

const HEALTH_PATTERN = new URLPattern({ pathname: "/health" });
// ...
if (HEALTH_PATTERN.exec(request.url)) {   // does NOT match "/health/"
    return next(request, info);
}

URLPattern({ pathname: "/health" }) does not match /health/ (or /health//). So /health/ falls through to the auth check, finds no Authorization header, and returns 401 — before the router ever runs (so it never reaches the 404 it would otherwise produce). The router's own /health route has the same exact-match behaviour, so even with a valid token /health/ yields 404, not 200.

Fix

Make the health bypass (and ideally the router) trailing-slash tolerant, e.g. match /health and /health/ explicitly, or normalize request.url's pathname by collapsing trailing slashes before matching. A targeted fix:

const HEALTH_PATTERN = new URLPattern({ pathname: "/health{/}?" });

Severity

Low: only affects the trailing-slash variant of one public endpoint. Real operational impact where probes are configured with /health/.

[jonbaldie]

This was generated by AI during triage.

Verification: Reproduced. GET /health → 200, GET /health/ → 401, GET /health// → 401, exactly as reported. Confirmed the auth bypass's URL pattern only matches the exact path /health, so trailing-slash variants fall through to the auth check and are rejected before the router (which has the same exact-match issue and would 404 them anyway) ever runs.

Agent Brief

Category: bug
Summary: The public /health endpoint returns 401 (not 200) for trailing-slash variants (/health/, /health//), because both the auth bypass and the router match the path exactly.

Current behavior:
/health returns 200 with no auth required, per openapi.yaml's security: []. /health/ and /health// are not recognized as the same endpoint by either the auth bypass or the router: the auth bypass rejects them with 401 (no Authorization header), and if a valid token were supplied they would 404 instead of reaching the health handler.

Desired behavior:
/health and its trailing-slash variants (/health/, at minimum) are treated as the same public endpoint: no authentication required, and the health handler responds 200.

Key interfaces:

• The URL pattern used to identify the health endpoint (used both for the auth bypass and for routing) should match the path with an optional trailing slash, not just the exact literal path.

Acceptance criteria:

• GET /health returns 200, unchanged.
• GET /health/ returns 200 with no Authorization header required.
• Authenticated (and other) routes are unaffected — no unintended trailing-slash tolerance is introduced for non-health paths.
• A test covers the trailing-slash health variant.

Out of scope:

• Trailing-slash tolerance for /health// (double slash) or any other route.
• Any change to the health endpoint's response body or status semantics beyond routing/auth matching.