Build fluency in the vocabulary of a fingerprint letting a client cheaply revalidate cached content.
0 / 5 completed
1 / 5
At standup, a dev mentions a server returning a short, opaque fingerprint of a resource's current content alongside its response, letting a client send that same fingerprint back on a later request so the server can reply with 'not modified' instead of resending the full body. What is this fingerprint called?
An ETag is a short, opaque fingerprint of a resource's current content that the server returns alongside its response, letting a client send that same value back on a later request, typically in an If-None-Match header, so the server can reply with a lightweight 'not modified' status instead of resending the full response body if the content hasn't actually changed. A CSRF token is an unrelated security mechanism verifying request origin, not content freshness. This fingerprint-and-compare mechanism is exactly what lets a client efficiently revalidate a cached resource without blindly trusting a fixed expiration time.
2 / 5
During a design review, the team has the client send its previously cached ETag in an If-None-Match header on every subsequent request for that same resource, letting the server decide whether the content has actually changed. Which capability does this provide?
This provides serving a lightweight 304 Not Modified response with no body when the content is unchanged, since the server can simply compare the client's submitted ETag against the resource's current fingerprint, and if they match, skip re-sending the full body entirely, saving meaningful bandwidth for a resource that hasn't actually changed since it was last fetched. Forcing a full resend on every request regardless of the ETag match would defeat the entire purpose of conditional requests. This conditional-request pattern is exactly what makes ETags valuable for efficiently revalidating cached content rather than relying purely on a fixed time-based expiration.
3 / 5
In a code review, a dev notices an endpoint generates its ETag from a resource's last-modified timestamp truncated to the nearest minute, even though the underlying content can change several times within that same minute. What does this represent?
This is an ETag granularity mismatch, risking a stale-content bug, since if the underlying content can genuinely change more than once within the same truncated minute, two different content states could end up producing the identical ETag, causing a client to wrongly receive a 304 Not Modified response and keep serving content that's actually out of date. A load-balancing algorithm is an unrelated concept about distributing traffic across backend instances. This is exactly why an ETag needs to be derived from something that reliably changes whenever the underlying content actually does, such as a content hash, rather than a timestamp truncated coarser than the content's real update frequency.
4 / 5
An incident report shows clients kept displaying outdated content even after a resource was updated, because the endpoint's ETag was derived from a last-modified timestamp truncated to the nearest minute, and the resource had actually changed twice within that same minute window. What practice would prevent this?
Deriving the ETag from a content hash, or any other value guaranteed to change whenever the actual content does, ensures two genuinely different content states can never produce the same ETag, which directly fixes the stale-content bug described in this incident. Continuing to derive the ETag from a coarsely truncated timestamp is exactly what let two distinct content states collide on the identical fingerprint. This content-derived ETag approach is the standard, robust way to guarantee an ETag actually reflects whether the underlying content has genuinely changed.
5 / 5
During a PR review, a teammate asks why the team uses ETags and conditional requests for a frequently accessed but rarely changing resource instead of just setting a long cache expiration time and letting the client trust that expiration blindly. What is the reasoning?
A fixed cache expiration time forces an uncomfortable choice: either the client keeps serving potentially stale content for the full duration of that expiration window, or it refetches the entire resource the moment the expiration passes, even if the content never actually changed. ETags let the client revalidate cheaply through a lightweight conditional request, paying the full bandwidth cost of a complete refetch only on the rare occasion the content has genuinely changed. The tradeoff is the small added round trip of the conditional request itself compared to simply trusting a cached copy until it expires, which is a worthwhile cost for a resource where both freshness and bandwidth efficiency actually matter.