Follow-up: ETag versus Last-Modified

Research run: 16 Sep 2026 · narrow follow-up to the bootstrap baseline.

Short answer: when a conditional GET or HEAD contains both validators, If-None-Match wins. A matching ETag can produce 304 Not Modified and the date is ignored. A nonmatching ETag means there is no If-Modified-Since fallback; assuming no earlier redirect or failure, the normal successful result is 200 OK.

ETag and date validation

Validator	What it represents	Trade-off
`ETag` → `If-None-Match`	An opaque server-selected identifier; cache validation uses weak entity-tag comparison.	Does not depend on a clock, but the server must choose compatible tags for the selected representation.
`Last-Modified` → `If-Modified-Since`	An HTTP-date for the selected representation.	Useful fallback, but date resolution and clock/restore behavior can be less precise.

RFC 9110 §13.1.3 says to ignore If-Modified-Since when If-None-Match is present. Its ordered algorithm in §13.2.2 evaluates the date only when the ETag condition is absent. Validator strength and comparison details are in §§8.8.1–8.8.3.

Precedence matrix

Request condition	Expected outcome	Reason
Matching ETag	`304 Not Modified`	ETag condition succeeds; a stored representation may be reused.
Nonmatching ETag	`200 OK` if the selected representation is otherwise successful	The ETag condition passes and the date is not consulted, even if the date would otherwise yield 304.
Date only, representation not newer	`304 Not Modified`	Date validation is the fallback when `If-None-Match` is absent.

Expected, not measured: this publication preserves the runner’s normative outcomes. No live curl capture was possible because the run environment had no curl executable. The matrix is not an observation of the MDN response, its status, or any cache hop.

Copyable diagnostic check

URL='https://example.test/resource'
curl -sS -D /tmp/headers -o /dev/null "$URL"
# Reuse the captured ETag and Last-Modified values:
curl -sS -D - -o /dev/null \
  -H 'If-None-Match: "current-tag"' \
  -H 'If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT' "$URL"
curl -sS -D - -o /dev/null \
  -H 'If-None-Match: "definitely-not-current"' \
  -H 'If-Modified-Since: <captured-date>' "$URL"

Record request and response headers at the same hop where possible. Inspect ETag, Last-Modified, Cache-Control, Age, Cache-Status, and Vary. A 304 identifies conditional semantics at the responding hop; it does not prove that a browser cache, CDN, service worker, or origin made the decision. Age and optional Cache-Status are not guaranteed to be exposed.

Sources and limits

RFC 9110 §13.1.3 and §13.2.2 define the precedence algorithm; §15.4.5 defines 304.
RFC 9110 §8.8 defines validator fields and strength; RFC 9111 §4.3 applies the precedence to cache validation.
MDN conditional requests and the ETag, Last-Modified, If-None-Match, and If-Modified-Since references provide developer context.
RFC 9211 §2 defines optional Cache-Status evidence.

The normative result assumes a GET/HEAD, a selected representation, no earlier redirect/error, and a compliant recipient. Intermediary rewriting, content negotiation, other preconditions, and deployment configuration can change an observed trace. The bootstrap report remains the source for the broader freshness, private/shared storage, and Cache-Control guidance.