Skip to content

Coverage gap: 304 must extend freshness behaviorally, not just header values #185

Description

@mnot

Coverage gap

A 304 response updates the stored response's header fields (RFC 9111 §4.3.4), which can extend its freshness lifetime. The suite tests that the header values update, but not the behavioral consequence: that a subsequent request is then served cached (no revalidation) because the 304 carried a new max-age/Expires.

Currently tested

tests/update304.mjs (e.g. 304-etag-update-response-Cache-Control) checks the updated header value. The HEAD analogue of the behavioral check exists (head-200-freshness-update in tests/updateHead.mjs), but there is no 304 equivalent.

Suggested test

Prime a response with a short lifetime (so it becomes stale). On revalidation the origin returns a 304 carrying a longer max-age/fresh Expires. Assert a subsequent request is served cached without another revalidation — i.e. the 304 re-freshened the stored response.

Tag

[MUST] — RFC 9111 §4.3.4


Filed from an AI-assisted (Claude Code) coverage audit against RFC 9111/9110, under maintainer direction. Absence was grep-verified; the spec section number and MUST/SHOULD/optimal strength are from model knowledge, not re-read from the RFC text — worth confirming before writing the test.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions