Background

Stateful MCP endpoints (streamable HTTP transport) receive a POST /mcp with the initialize body. If the server is behind a reverse proxy that redirects http:// to https:// via 301 Moved Permanently, the client may legally convert the POST to a GET on the redirected URL — per RFC 7231 §6.4.2 ("a user agent MAY change the request method from POST to GET for the subsequent request").

The MCP server then receives a bodyless GET, returns 400, and the client has no clear signal about why the session failed. This is a silent compatibility gap.

Empirical observation

Over five days of operating a public MCP server, I catalogued eight independent client implementations connecting from the wild. Two of them fail exclusively at the HTTP→HTTPS redirect step:

• A client (MCP-Client/1.0) that issues POST http://…/mcp, receives 301 → https://…/mcp, follows it as GET, gets 400, loops indefinitely through path discovery, reads the homepage as a fallback discovery step, and restarts.
• A second client (unidentified UA) that has been hitting this wall for three days across 140+ attempts.

Both clients issue a correctly-formed MCP initialize body when reaching the HTTPS URL directly. The redirect is the only failure point.

Proposed recommendation

The spec (or a deployment best-practices note) could note:

MCP servers SHOULD NOT respond to stateful endpoints (/mcp, etc.) with 301 or 302 redirects. If HTTP→HTTPS redirection is necessary, use 308 Permanent Redirect (RFC 7538), which MUST NOT change the request method, preserving the POST body through the redirect chain.

Server operator fix (nginx):

# In the HTTP server block:
return 308 https://$host$request_uri;

This is a one-line configuration change that eliminates the silent failure for a class of correct clients.

Questions for the working group

1. Is this within scope for a normative note in §6 (HTTP transport)? Or better suited to a non-normative deployment annex?
2. Should the server signal this more explicitly — e.g., include a Link header or discovery hint so clients know to switch to HTTPS before the redirect?
3. Are there client-side mitigations worth recommending (e.g., clients SHOULD follow redirects while preserving method)?

Happy to open a PR with a specific text proposal if there's interest.

Data source: production observation log at https://github.com/Aigen-Protocol/aigen-protocol/blob/main/docs/SECOND_IMPLEMENTATION.md — eight client architectures with failure modes.