Add 204 and 308 to heuristically cacheable status codes#13015
Add 204 and 308 to heuristically cacheable status codes#13015bryancall wants to merge 2 commits intoapache:masterfrom
Conversation
RFC 9110 Section 15.1 defines 204 (No Content) and 308 (Permanent Redirect) as heuristically cacheable by default, but they were missing from the allowlist in is_response_cacheable(). This meant these responses would only be cached via negative caching configuration rather than being treated as cacheable by default like their counterparts (200 and 301).
There was a problem hiding this comment.
Pull request overview
Updates ATS core cacheability heuristics so that responses with HTTP 204 (No Content) and 308 (Permanent Redirect) are treated as heuristically cacheable by default (consistent with the existing allowlist behavior for similar status codes).
Changes:
- Add
HTTPStatus::NO_CONTENT(204) to the status-code allowlist inHttpTransact::is_response_cacheable(). - Add
HTTPStatus::PERMANENT_REDIRECT(308) to the same allowlist.
Verifies that responses with heuristically cacheable status codes (200, 203, 204, 300, 301, 308, 410) are cached when only Last-Modified is present (no Cache-Control or Expires), and that non-cacheable codes (302, 307, 400, 403) are not cached. Negative caching is disabled to isolate the heuristic path.
RFC 9110 Heuristic Caching Gap AnalysisWhile adding 204 and 308, I checked the full list of heuristically cacheable status codes from RFC 9110 Section 15.1. ATS is still missing four codes from the allowlist in
The four missing codes (404, 405, 414, 501) are currently only cached when Adding these to the heuristic allowlist would be a behavior change for existing deployments -- particularly for 404, where many operators rely on the current default of not caching 404s without explicit negative caching configuration. Keeping this PR scoped to just 204 and 308, but will open a separate issue to track the remaining gaps. |
RFC 9110 Section 15.1 defines 204 (No Content) and 308 (Permanent Redirect) as heuristically cacheable by default, but they were missing from the allowlist in is_response_cacheable(). This meant these responses would only be cached via negative caching configuration rather than being treated as cacheable by default like their counterparts (200 and 301).