LEARN. PRACTICE. GROW.A validator needs a representation
An ETag is opaque: the client need not interpret it as a number, date or checksum. Keep it associated with the resource, variant and retrieved body. In a reporting job, retaining the ETag table while deleting the files breaks that association. The next 304 response does not deliver a new body to replace the missing one. Before publishing the result, confirm that the corresponding representation still exists and meets functional criteria. Otherwise, recover it through a read without that validator.
Choose comparison according to intent
With ETag "v1", a GET using If-None-Match: W/"v1" can receive 304 because this field uses weak comparison. The same weak text in If-Match does not satisfy the strong comparison required for write protection. In the lab, PUT with W/"v1" receives 412 and state remains alpha. Do not simply remove W/ to invent a stronger guarantee. Obtain an appropriate validator under the contract and confirm how the API evaluates the condition before applying changes.
Reconciliation requires more than replacing a header
Ana and Bruno read the same configuration version. Ana publishes a change and the server moves from v1 to v2. Bruno tries replacing the body based on v1; the fixture rejects it with 412. Recovery requires reading v2, comparing both intentions and constructing a coherent proposal. Copying the new ETag onto the old body can remove the visible error while losing Ana’s work. At a change committee, identify who decides content conflicts and who approves deferring a change.
Existence, version and required precondition
Distinguish three contracts. If-Match with an explicit ETag tests the selected version; If-Match: * requires existence without protecting the exact version read. If-None-Match: * on PUT can express creation only when no representation exists yet. A server can respond 428 when the contract requires a missing precondition. In the fixture, a PUT without If-Match receives that status. Wildcards and validator precedence are covered from documentation in this lesson; the runner does not implement a general parser for every HTTP condition.
Execute and read the local experiment
Run run.py from the project root. The first GET receives alpha and "v1" the conditional GET receives 304 without a body. A valid write with "v1" produces beta and "v2" a subsequent attempt based on "v1" receives 412 and leaves beta intact. Inspect events, headers and final body in evidence.json. These results were executed with curl 8.7.1. State lives only in memory and requests are sequential, so the experiment demonstrates neither distributed atomicity nor persistence after restart.
Apply the reasoning to support and projects
In a handover, provide the precondition contract, a conflict example and the reconciliation procedure, including who authorizes repeating the write. Confirm that the real implementation evaluates the condition and changes state appropriately for its architecture. The presence of an ETag in a response does not prove that behavior. For read tests, preserve body and metadata for the correct variant. When If-None-Match and If-Modified-Since coexist, ETag comparison takes precedence; do not choose whichever condition merely produces the smaller response.
# From the project root; synthetic local data only
python3 content/labs/http-conditions/run.py
# evidence.json: conditionalRead, validatorComparison, conditionalWrite
# Accepted write: v1 -> v2, alpha -> beta
# Rejected stale write leaves beta intactFictional case: two operators change batch limits. The second receives 412, compares current state and retries only after reconciling limits, retaining the already approved change.
Common pitfalls
Do not turn 304 into an empty body, manually convert weak validators, or merely replace an ETag to bypass 412 without reviewing content.
Related topics: Methods, statuses, and controlled retries · Caching, variants, and validation · Diagnosis and time budgets
A validator has context; a rejected write needs reconciliation, and actual assurance depends on the implementation evaluating and applying the precondition.
Reference: HTTP Semantics · BigSavant HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance