parlov docs

Forcing 406 Not Acceptable

Per RFC 9110 §12.5.6, a server performing proactive content negotiation may send 406 when it cannot produce a representation matching the Accept value.

Implemented

Mechanism: Per RFC 9110 §12.5.6, a server performing proactive content negotiation may send 406 when it cannot produce a representation matching the Accept value. The server must first locate the resource — so a 406 implies the resource was found.

Isolated Variable: Only the Accept header changes.

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

HEAD — Existing Resource

HEAD /api/users/1001 HTTP/1.1
Host: target.com
Accept: application/x-nonexistent

HTTP/1.1 406 Not Acceptable

HEAD — Non-Existing Resource

HEAD /api/users/9999 HTTP/1.1
Host: target.com
Accept: application/x-nonexistent

HTTP/1.1 404 Not Found

💡 Note: Many servers ignore Accept entirely and serve their default representation, returning 200 for existing resources. The oracle still exists (200 vs 404) but it's the same signal as the baseline.

Mitigation: Return 404 for all requests targeting a non-existent resource before evaluating content negotiation headers.