428: Require a condition
01A server asks for a conditional update instead of letting an unconditional write overwrite someone else’s work.
Separate retry: the current ETag is still "v7", so this illustrated conditional PUT succeeds with 204. A false condition prevents a new update; 412 can indicate that failure. An operation already applied has a separate exception in HTTP semantics.
Source for this drawing: RFC 6585 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Precondition
- A check the server evaluates before performing an operation.
- Lost update
- An update overwrites another writer’s newer state.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Require a precondition before accepting an update, then evaluate it.
- 428 Precondition Required means the origin server requires the request to be conditional. Supporting this status code is optional; clients cannot rely on it to prevent lost updates.
- The 428 response SHOULD explain how to resubmit successfully and MUST NOT be stored by a cache. If-Match is one possible condition, not a required header for every 428 response.
- In this worked example, an unconditional PUT receives 428. A separate retry with If-Match: "v7" succeeds only while the current representation still matches. A present but false If-Match condition prevents performing a new update; 412 can report that failure, rather than asking for a missing condition with 428.
An entity tag (ETag) is an opaque representation validator, not a revision number with arithmetic meaning. If-Match uses strong comparison. The v7 spelling and 204 response are examples. RFC 9110 §13.1.1 also permits a 2xx response when a state-changing operation appears already applied; the drawing illustrates a new update. See §15.5.13 for 412.
Read the RFC section ↗