Skip to content

Coverage gap: HEAD revealing a changed validator must invalidate #186

@mnot

Description

@mnot

Coverage gap

Per RFC 9111 §4.3.5, if a response to a HEAD request reveals that the selected representation changed (e.g. a different ETag, Content-Length, or Last-Modified), the cache must invalidate the stored response — not merge fields into it. The suite only tests HEAD updating stored fields, never the invalidation-on-changed-validator case.

Currently tested

head-200-update (tests/updateHead.mjs) changes a benign field (Template-A) and expects a merge (cached). No test where the HEAD's validator differs from the stored one.

Suggested test

Prime a stored GET response (ETag "a", some Content-Length). Issue a HEAD whose response has a different ETag ("b") / different Content-Length. Assert the stored response is invalidated — a subsequent GET is not_cached (forwarded), not served from the old stored entry.

Tag

[MUST] — RFC 9111 §4.3.5


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