lighttpd: bare /mcp (no trailing slash) returns 404 — breaks MCP clients that strip the trailing slash

[noahsprent]

Summary

The lighttpd rewrite rule for the MCP endpoint only matches /mcp/... (with a trailing slash), so a request to the bare path /mcp returns 404 instead of reaching the FastCGI MCP app. This breaks remote MCP clients that normalize away the trailing slash (e.g. Claude's web connector), since they connect to https://<host>/mcp.

Location

packaging/linux-leader/files/lighttpd/50-pioreactorui.conf

url.rewrite-once = (
  "^(/static($|/.*))$"   => "$1",
  "^(/api/.*)$"          => "/api.fcgi$1",
  "^(/unit_api/.*)$"     => "/api.fcgi$1",
  "^(/mcp/.*)$"          => "/api.fcgi$1",   # <-- requires trailing slash
)

Why bare /mcp 404s

A request to /mcp (no trailing slash):

1. does not match "^(/mcp/.*)$", so it is never rewritten to /api.fcgi, and
2. is excluded from the SPA fallback by the negative match block:

   $HTTP["url"] !~ "^(/api($|/)|/api\.fcgi($|/)|/unit_api($|/)|/mcp($|/)|/static($|/)|/exports($|/))" { ... }
   

   (/mcp matches /mcp($|/), so the SPA rewrite is skipped too)

With no rewrite from either branch, lighttpd tries to serve /mcp as a static file and returns 404.

Reproduce

On a leader exposing the UI:

curl -i -X POST http://127.0.0.1/mcp  -H 'Content-Type: application/json' -d '{}'   # -> 404
curl -i -X POST http://127.0.0.1/mcp/ -H 'Content-Type: application/json' -d '{}'   # -> reaches MCP app

The MCP backend itself handles both paths fine — the discrepancy is purely in this rewrite rule. The MCP spec doesn't require clients to preserve a trailing slash on the server URL, and several do strip it, so the bare-path case needs to work.

Suggested fix

Widen the pattern to also match the empty (bare) case:

-  "^(/mcp/.*)$"          => "/api.fcgi$1",
+  "^(/mcp($|/.*))$"      => "/api.fcgi$1",

This is low-risk: it only adds the bare /mcp path; existing /mcp/... behaviour is unchanged. I've been running this patch on a leader (pioreactor 26.5.2) and /mcp now reaches the MCP app — verified end-to-end through a Cloudflare Tunnel + Cloudflare Access, where the bare path now returns the expected MCP OAuth 401 challenge instead of a 404.

(Note: /api and /unit_api carry the same trailing-slash-only pattern, but no client connects to those bare roots, so this report is scoped to /mcp.)

[noahsprent]

Clearly claude wrote this issue... basically in trying to connect the MCP to claude web even if I put /mpc/ it immediately removes the trailing slash. I suppose it's a bug in claude but felt easier to fix here?

[noahsprent]

Correction / fuller analysis — my original suggested fix above ("^(/mcp($|/.*))$") is incomplete. It makes POST /mcp reach the app, but the bare-path GET (which Streamable-HTTP clients send to open the optional SSE stream) still 404s, so connectors like Claude's still fail. There are two layers:

Layer 1 (lighttpd): the original "^(/mcp/.*)$" rule doesn't match bare /mcp, so it isn't rewritten to FastCGI → lighttpd 404.

Layer 2 (the app): the MCP blueprint is POST-only:

mcp_bp = Blueprint("mcp", __name__, url_prefix="/mcp")
@mcp_bp.post("/", strict_slashes=False)

strict_slashes=False makes POST work on both /mcp and /mcp/, but a GET returns 405 at /mcp/ and 404 at bare /mcp (Werkzeug finds no method-match for the bare path). A client that strips the trailing slash does GET /mcp, gets 404, and concludes the endpoint doesn't exist. Per the Streamable HTTP spec a POST-only server should answer GET with 405, not 404.

Observed matrix before the fix (origin, bypassing any auth):

	/mcp	/mcp/
POST	200	200
GET	404	405

Fix that covers both layers — rewrite a bare /mcp to the app's slashed path so the app always sees /mcp/:

-  "^(/mcp/.*)$"          => "/api.fcgi$1",
+  "^/mcp$"               => "/api.fcgi/mcp/",
+  "^(/mcp/.*)$"          => "/api.fcgi$1",

After this, bare /mcp matches /mcp/ for every method — POST → 200, GET → 405 (not 404) — and Claude's connector connects. (Alternatively/additionally this could be fixed at the app layer by giving the route an explicit GET handler that returns 405, but the lighttpd normalisation is transport-agnostic and lives in the file already shipped here.)

Verified on a leader running pioreactor 26.5.2, end-to-end through Cloudflare Tunnel + Access.

[noahsprent]

Quick clarification so the repro stays clean: the authoritative reproduction is the localhost matrix against the origin (in my comment above) — GET /mcp → 404 vs GET /mcp/ → 405, no proxy involved.

My original post mentioned the bare path "returning the OAuth 401 instead of 404 through Cloudflare Access" — disregard that as evidence. When Cloudflare Access (Managed OAuth) fronts the server, it answers unauthenticated requests with the 401 challenge itself, before they ever reach the origin, so that 401 is independent of this fix and isn't part of the repro. The bug is purely origin-side and is most directly hit on direct/LAN/Tailscale access (no auth proxy), or post-authentication behind a proxy.

[CamDavidsonPilon]

👍 I've noticed this too. This will be fixed for the next release