📡 ToastRFC

cacheable

a response is cacheable if a cache is allowed to store a copy and reuse it for a later request

Cacheability is a property of a response, governed by the method, the status code, and the Cache-Control / Expires / Vary fields. By default, responses to GET and HEAD are cacheable, and a handful of status codes (200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, 451) are cacheable "by default" — meaning a cache may store them even without explicit freshness information. Everything else needs an explicit Cache-Control directive to be stored.

How it is read

RFC 7234 (2014)

spec

The previous HTTP caching spec. Defined the heuristic-freshness model and the default-cacheable status codes.

RFC 9111 (2022)

spec

Obsoletes 7234. Same core model, with clarified handling of Cache-Control extension directives, the must-understand directive (new), and partial-content (206) storage. This is the spec that governs HTTP caching today.

In the corpus (1)

HTTP Caching