Skip to content

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

@mnot

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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions