Self-hosted: empty-body POST requests intermittently/consistently fail with FST_ERR_CTP_INVALID_MEDIA_TYPE (500)

[robin-scharf]

Environment

• Self-hosted, Docker Compose deployment (official infisical/infisical image)
• Reproduced on both v0.161.5 and v0.161.10
• Reverse proxy: Traefik -> Cloudflare in front (headers pass through cleanly, confirmed via manual curl reproduction)

Bug

Several endpoints that are called with an intentionally empty body (no Content-Type header, Content-Length: 0 — correct behavior per the client, since there's nothing to send) fail server-side with:

FastifyError: Unsupported Media Type
    at ContentTypeParser.run (/backend/node_modules/fastify/lib/content-type-parser.js:195:16)
    at Object.handleRequest (/backend/node_modules/fastify/lib/handle-request.js:50:48)
    at runPreParsing (/backend/node_modules/fastify/lib/route.js:651:19)
    at next (/backend/node_modules/fastify/lib/hooks.js:236:9)
    at handleResolve (/backend/node_modules/fastify/lib/hooks.js:253:7)
code: 'FST_ERR_CTP_INVALID_MEDIA_TYPE', statusCode: 415

The response returned to the client is a 500 ({"statusCode":500,"message":"Something went wrong","error":"InternalServerError"}) rather than the underlying 415.

Endpoints observed affected

• POST /api/v1/user/me/webauthn/register — consistently reproduces, 100% of attempts, on both versions tested. This makes it impossible to register a new WebAuthn/passkey credential on affected instances.
• POST /api/v1/auth/token — intermittent, observed during MFA code submission (some attempts fail, retry sometimes succeeds).
• POST /api/v1/auth/logout — intermittent, same signature.

Confirmed via browser DevTools Network tab that the actual request sent has no Content-Type header at all and Content-Length: 0 — this is valid per the Fetch/HTTP spec for a bodyless POST. Manually replaying requests with an explicit Content-Type: application/json header (even with an empty {} body) does not reproduce the error, which points at Fastify's content-type parser not gracefully handling the "no body, no Content-Type header" case on these particular routes/hooks.

Steps to reproduce (most reliable: WebAuthn registration)

1. Log in to a self-hosted instance.
2. Go to Personal Settings -> Authentication -> add a new Passkey/WebAuthn device.
3. Click "Add".

Expected: Server returns WebAuthn registration challenge options.
Actual: 500 Internal Server Error every time; backend log shows FST_ERR_CTP_INVALID_MEDIA_TYPE as above.

Impact

Blocks adding/re-adding WebAuthn passkeys entirely on affected self-hosted instances. Also causes occasional login/logout failures requiring a retry.

Happy to provide more logs/details if useful.

[linear]

ENG-5315

[jaydeep-pipaliya]

Sent a fix — the wildcard content-type parser in app.ts accepts the empty body and leaves non-empty bodies to the specific parsers. Should unblock WebAuthn registration and the intermittent /auth/token and /auth/logout failures. PR up.