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.
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 AcceptableHEAD — 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
Acceptentirely and serve their default representation, returning200for existing resources. The oracle still exists (200vs404) 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.