Two staff members can open the same specification and unknowingly overwrite each other. A “saved successfully” message says little unless the system checks the version that was actually edited. This brief helps a business owner define a conflict response before buying shared CMS editing.
What the standard supports
HTTP Semantics, RFC 9110 section 13.1.1 describes strong If-Match comparison for conditional updates and preventing lost updates. Checked 16 October 2026. A stale precondition must not perform the requested change; the fixture uses a 412 response. An ETag is not automatically a human revision number or a document approval.
Filled two-editor trace
Synthetic example: both editors load revision 7 with strong validator "r7". Editor A changes an installation note and saves revision 8. Editor B still holds revision 7 and tries to save a different change.
On narrow screens, scroll sideways to read the full table.
| Action | Current validator | Submitted If-Match | Expected result |
|---|---|---|---|
| A saves revision 8 | "r7" | "r7" | 200; current revision becomes 8 |
| B saves stale content | "r8" | "r7" | 412; keep revision 8 |
| B reloads and reviews merge | "r8" | "r8" | 200; new approved save may become 9 |
| Weak validator control | W/"r8" | W/"r8" | Not a strong match; do not apply |
| No validator supplied | "r8" | Missing | Outside fixture; require explicit policy |
Choose the user-facing behaviour
The system should preserve B’s unsaved draft, explain that a newer revision exists and offer review/reload or a controlled merge. It should not silently replace revision 8 or discard B’s work. If a supplier uses revision IDs instead of HTTP validators, require the equivalent atomic comparison and demonstrate its behaviour.
Acceptance steps
- Open the same test record in two isolated editor sessions.
- Save A, then attempt B’s stale save.
- Confirm the server record still contains A’s change and B retains an inspectable draft.
- Review and deliberately submit the combined revision. Repeat with two genuinely concurrent saves against the same version.
What to collect
Record the record ID, expected version or strong validator, current version, response status and resulting content hash. In this fixture a conflict is a correct protective outcome. A screenshot of a toast without the stored record is insufficient to prove that no overwrite occurred.
Limits
The downloadable function is an exact-match teaching model, not an HTTP server, merge engine or backup system. It excludes duplicate-success handling, access control, caches, approval workflows and restore operations. Do not apply it to production without server-side verification. It makes no claim about a particular CMS or existing MadRaven page.
Replay the teaching example
These files run locally without network access. They model only the stated cases, not a live vendor integration. Filled inputs and expected results · Inspectable teaching functions
Save both files in one folder. With Node 22.13 or newer, run:
node decision-check.mjs cms-stale-save-contract.json