Phase 1 exposure now verified end to end (2026-08-12): /healthz -> ok and an
unauthenticated POST /mcp -> 401, both from a client container and from the
primary itself. 3.4 and 3.6 marked passed.
Two findings from the failure in between, worth more than a checkbox:
1. Leaving Pangolin's resource authentication on does NOT surface as 401 or 403.
It is a 302 with `location: https://pangolin.jordbo.se/auth/resource/<uuid>
?redirect=...`, sent *before* the request is proxied -- so the palace never
sees it and its journal stays silent, `curl -s` prints an empty body, and an
MCP client gets non-JSON. That is 1.1's "Pangolin's HTTP auth is
browser-shaped; the clients are not" arriving as a concrete symptom rather
than an argument. Now recorded with the exact header shape and the two curl
flags that reveal it (-D-, -w '%{redirect_url}'), plus the reading: a 302 is
good news, because DNS, TLS and routing all worked and only auth intervened.
2. Read the server's routing to settle whether path-scoped proxy rules are
sufficient. The entire HTTP surface is two exact paths (mcp_server.py:5299-
5318): GET /healthz (no token, Host/Origin gated) and POST /mcp (Bearer,
compare_digest on the exact string). Everything else is a 404 from the palace
itself. So path-scoped rules are tighter than a host-wide proxy and lose
nothing. Two client-facing consequences: /mcp is matched exactly, so a
trailing slash 404s -- configure clients without one; and there is no GET
/mcp, no SSE, no session id, no DELETE, so this is plain JSON-RPC over POST,
not MCP streamable-HTTP. A strict client opening with a GET handshake sees
404. Also means the verify step needs no initialize and no Accept:
text/event-stream, which the old snippet left ambiguous.
Also: run the 200 and 401 from two different networks, not one -- passing from
only the primary leaves split-horizon DNS untested.
Joakim Persson
4cb70ce3e1