parlov docs

Forcing 415 Unsupported Media Type

Per RFC 9110 §15.5.16, a server returns 415 when the content type is not supported.

Implemented

Mechanism: Per RFC 9110 §15.5.16, a server returns 415 when the content type is not supported. Many pipelines validate Content-Type after resolving the resource, creating the differential.

Isolated Variable: Only the Content-Type header changes to an invalid value. The request body remains well-formed.

Oracle Signal: 415 (exists) vs 404 (does not exist).

POST — Existing Parent Resource (Sub-Resource Endpoint)

POST /api/users/1001/actions HTTP/1.1
Host: target.com
Content-Type: application/x-invalid
Content-Length: 18

{"action": "lock"}

HTTP/1.1 415 Unsupported Media Type

vs. 404 when user 1001 does not exist.

💡 Collection endpoints: POST against a collection (e.g., POST /api/users) validates Content-Type against the collection's accepted types regardless of any child resource's existence — no per-resource oracle. Only use this technique when POST targets a specific parent resource.

Mitigation: Validate Content-Type at the routing layer before resource resolution.