Summary

  • A 304 Not Modified response answers a conditional HTTP question about a selected representation and allows a cache to update stored metadata; it is not a general certificate of upstream dependency currency.
  • Operators should bind validator evidence to the data lineage behind a representation before treating a successful revalidation as permission to make a current business decision.

Imagine a configuration endpoint backed by a database snapshot. A cache sends If-None-Match with the entity-tag it already holds. The origin compares the condition against the selected representation and returns 304 Not Modified. No new representation content travels over the wire. The cache updates the stored response as the protocol allows, and a dashboard turns the green revalidation event into a broader label: “dependency chain verified.”

That last step is where protocol evidence becomes managerial fiction. The 304 can be entirely correct even if the database snapshot used by the application is older than the business decision permits. HTTP has answered the question it was given. The dashboard has silently substituted another.

The condition has a defined object

RFC 9110 defines If-None-Match in terms of entity-tags for the selected representation. For a conditional GET or HEAD, a false condition leads to a 304 instead of the 200 response that would otherwise carry content. The result is useful precisely because it has a bounded meaning: the validator condition was evaluated for the target representation under HTTP semantics.

A 304 response therefore is not an empty 200. It has no content, but it can carry fields needed to guide caches. Depending on the request and response, those fields include ETag, Date, Cache-Control, Expires, Content-Location, and Vary. The response lets a cache reconcile stored metadata without transferring the full representation again.

RFC 9111 then specifies how a cache identifies stored responses to update. Strong and weak validators do not play identical roles. Once the corresponding stored response is identified, the cache replaces applicable stored header fields with those supplied in the 304, subject to the specification's exclusions. This is a disciplined metadata operation, not a declaration about every system that influenced the response.

Representation validity is not dependency currency

An entity-tag belongs to the representation semantics chosen by the origin. An application might calculate it from final bytes, from a version field, from a deployment identifier, or from another implementation-specific input. HTTP does not require that identifier to encode the version of every database row, policy bundle, feature flag, entitlement feed, or external API result consulted upstream.

That distinction matters whenever a representation is derived from a chain. Suppose the endpoint's JSON bytes have not changed since the cache stored them. A 304 can be the correct response. But if those bytes were computed from a snapshot that should have refreshed five minutes ago and did not, the unchanged representation may preserve the very staleness an operator needs to discover. Revalidation confirms continuity at the validator boundary; it does not widen that boundary after the fact.

This is not an argument against conditional requests. They reduce transfer, protect bandwidth, and make caches efficient. Nor is it a claim that every 304 hides stale data. It is a claim about evidence scope. A control should never promote “the selected representation still matches this validator” into “all dependencies are current” without additional proof.

Ask for the missing lineage

The missing evidence is usually available, but it sits outside the status code. A high-consequence configuration response can expose or log a dependency snapshot identifier, source update time, policy-bundle version, or materialization watermark alongside its representation validator. The cache can record the request target, stored-response identity, conditional fields, 304 metadata, and the exact decision that consumed the result.

The resulting validation-chain receipt does not replace HTTP. It preserves what HTTP proved and appends what the operating decision needs. It is an editorial control synthesis, not an object defined by the IETF or either cited RFC. Its minimum useful fields are:

  • request target and selected representation identity;
  • validator type and value, plus the conditional request fields;
  • response time, status, and the metadata returned with the 304;
  • stored-response identity and the fields updated after validation;
  • upstream snapshot, policy, or dependency versions used to form the representation;
  • the decision, control, or automation that relied on the cached result.

Such a receipt also makes uncertainty visible. If the origin cannot bind the representation to a dependency version, the honest state is “representation revalidated; dependency currency unknown.” That is a narrower claim, but it is far more useful than a green badge that collapses two different questions.

Sources