2026-09-28 · 5 min read · Rahul Chitturi
- http
- concurrency
- api
HTTP 412 Precondition Failed means the server evaluated one or more request preconditions as false. For state-changing requests, If-Match commonly prevents a stale client from overwriting a representation that changed after it was read.
A 412 is usually concurrency protection working as designed. Blindly retrying the same write removes the opportunity to reconcile the user's intent with current state.
Capture the validator round trip
Record the retrieval status, request URL, content negotiation headers, returned ETag or Last-Modified value, write method, precondition headers, authenticated principal, and 412 response. Preserve quotes, weak prefixes, and timestamp precision exactly.
- Use a strong validator for If-Match comparisons.
- Do not hash a reformatted body and assume it is the server ETag.
- Keep validators scoped to the selected representation.
- Check whether a proxy transformed or removed headers.
Distinguish stale state from malformed handling
Fetch the current representation through the same variant and authorization context, then compare its validator with the one sent. If state changed, show or merge the conflict explicitly. If it did not, inspect validator generation, variant keys, compression, and middleware.
Date-based conditions have limited precision and depend on server timestamps, so prefer entity tags where exact lost-update prevention matters.
Exercise competing writers
Use Flashman's URL parser for resource identifiers, hash tool for public body fixtures, timestamp converter for Last-Modified tests, and diff for old-versus-current representations.
Test unchanged writes, two simultaneous editors, deleted resources, weak and strong tags, wildcard conditions, negotiated variants, clock boundaries, proxy revalidation, authorization changes, retries, and atomic check-and-write behavior.