HTTP 412 precondition failed

What a precondition is

HTTP 412 Precondition Failed means a conditional request was refused because a condition declared in one of its request headers did not hold. Conditional requests let a client say, in effect, "only do this if the resource still looks the way I last saw it." The server evaluates those conditions and, when a guard fails, returns 412 instead of performing the operation. This is the mechanism that prevents lost updates, so it is common on PUT and PATCH endpoints, uploads and synchronising applications.

The status is narrowly about a failed precondition, which is why it is distinct from 409; the conflict article covers that difference and where a resource-state conflict applies instead.

The two validators

The preconditions use two kinds of validator:

A typical update flow is: a client GETs a resource and stores its ETag, then sends a PUT with that ETag in If-Match. If another client has since modified the resource, the server returns 412 and the write is rejected, preserving the newer state instead of silently overwriting it. When a request carries both If-Match and If-Unmodified-Since, the server evaluates If-Match and ignores the date-based condition, because the ETag is the stronger validator. See the HTTP caching article for where ETag and Last-Modified are assigned to responses in the first place.

Fix the stale validator

A 412 is a signal that the client's view of the resource is out of date, so the fix is a fresh read, not a retry with the same stale value. The ordered approach:

1. Refetch the resource with a GET so you receive the current ETag (or Last-Modified).
2. Reapply the user's last edit on top of the new state, then resend the operation with the fresh validator.
3. If the resource is user-edited, surface the conflict in the UI as others have made changes since the user's copy, rather than silently overwriting them.
4. Check whether the failure is consistent and one-sided. A persistent 412 often means the client is always sending a stale ETag, which points at a bug in how the client caches or compares the tag.

When a 412 appears for a manual action such as a CMS or plugin update, the same rule holds: the stored version marker is stale, so refresh the resource and retry, and involve the 400 bad request article if the request is otherwise malformed. Prefer ETag/If-Match over date validators for precision, because timestamps only have one-second resolution and can silently miss a mid-second change.