ETags, conditional requests and lost updates

An ETag is a validator: an opaque string the server attaches to a representation that changes whenever the representation changes — often a version number or a hash of the body.

HTTP/1.1 200 OK
ETag: "v42"
Cache-Control: no-cache

{"id": "7", "name": "Nino", "plan": "pro"}

A tag is quoted. Prefixed with W/ (W/"v42") it is a weak validator, meaning "semantically equivalent" rather than "byte for byte identical" — useful when, say, compression or whitespace may differ.

Revalidation: If-None-Match and 304

When a cached copy is stale (or marked no-cache), the client sends its tag back and asks the server to send the body only if it changed:

GET /users/7 HTTP/1.1
If-None-Match: "v42"

If the current tag matches, the answer is 304 Not Modified with no body, and the client reuses what it has. The request still costs a round trip, but not the payload — and often not the database work, if the server can compute the tag cheaply.

Two comparisons

RFC 9110 defines two ways to compare tags:

• Strong comparison — both tags are strong and their opaque parts are identical.
• Weak comparison — the opaque parts are identical, whether or not either is weak.

If-None-Match uses weak comparison (a weak match is good enough to reuse a cached copy). If-Match uses strong comparison, so a weak tag can never satisfy it.

1const isWeak = (t) => t.startsWith("W/");2const opaque = (t) => (isWeak(t) ? t.slice(2) : t);3 4const strongMatch = (a, b) => !isWeak(a) && !isWeak(b) && opaque(a) === opaque(b);5const weakMatch = (a, b) => opaque(a) === opaque(b);6 7export function run() {8  const pairs = [9    ['"v1"', '"v1"'],10    ['W/"v1"', '"v1"'],11    ['W/"v1"', 'W/"v1"'],12    ['"v1"', '"v2"'],13  ];14  return pairs.map(([a, b]) => `${a} vs ${b}: strong ${strongMatch(a, b)}, weak ${weakMatch(a, b)}`);15}

Lost updates, and If-Match

Two people open the same record, both at version "v42". The first saves a change; the second saves theirs a minute later and silently overwrites the first. Nobody gets an error. That is a lost update, and it is exactly what conditional writes prevent — optimistic concurrency, with no locks held between requests:

PUT /users/7 HTTP/1.1
If-Match: "v42"

The server performs the write only if the current tag still matches. If someone changed the resource in between, the condition is false and the answer is 412 Precondition Failed; the client re-reads, merges or asks the user, and tries again with the new tag.

1function makeResource() {2  let version = 42;3  let doc = { name: "Nino", plan: "free" };4  return {5    get: () => ({ etag: `"v${version}"`, doc: { ...doc } }),6    put(body, ifMatch) {7      if (ifMatch !== undefined && ifMatch !== `"v${version}"`) return 412;8      doc = body;9      version += 1;10      return 200;11    },12    current: () => doc,13  };14}15 16export function run() {17  const results = {};18  for (const conditional of [false, true]) {19    const r = makeResource();20    const alice = r.get();21    const bob = r.get();22    const a = r.put({ ...alice.doc, plan: "pro" }, conditional ? alice.etag : undefined);23    const b = r.put({ ...bob.doc, name: "Nino K." }, conditional ? bob.etag : undefined);24    results[conditional ? "withIfMatch" : "plain"] = { statuses: [a, b], final: r.current() };25  }26  return results;27}

Two more tools complete the picture:

• If-None-Match: * on a PUT means "only if nothing exists here yet": a create that cannot overwrite.
• 428 Precondition Required (RFC 6585) lets a server insist on a conditional request, so a client that forgets If-Match is refused instead of risking a lost update.

When both headers are present, RFC 9110 evaluates If-Match first, then If-None-Match.

Common mistakes

• Updating with a plain PUT and no precondition, so the last writer wins and earlier changes vanish without an error.
• Comparing a weak tag with If-Match. Weak tags never pass strong comparison.
• An ETag that does not change when the representation does (for example, derived only from the row's id), which makes every 304 a lie.
• Answering a failed If-None-Match on a PUT with 304. For GET and HEAD a false If-None-Match is 304; for other methods it is 412.

What interviewers ask

• How do ETags reduce bandwidth? — the client sends If-None-Match with its tag; a match returns 304 with no body.
• Two users edit the same record. How do you stop one overwriting the other? — optimistic concurrency: send If-Match with the tag that was read; the server returns 412 if it changed; optionally require it with 428.
• Strong versus weak ETags? — strong means byte-identical and is required for ; weak means equivalent and is enough for cache revalidation.