Methods and caching

A quick guide to decide “Will this be cached?” for each method. HTTP semantics are defined by RFC 9110; caching rules by RFC 9111.

Cache basics

The method, status, and headers determine whether storage is allowed. Actual storage also depends on browser or CDN implementation and configuration.

Method	Cacheability	Notes
GET	Cacheable	Storage depends on status, authentication, Cache-Control, and other cache requirements.
HEAD	Cacheable	Same as GET, without a body.
POST	Normally not cached	Requires explicit freshness information and Content-Location equal to the target URI; see below.
PUT/DELETE	Not cacheable	Responses to these methods cannot be cached.
PATCH	Conditionally cacheable	RFC 5789 requires explicit freshness and Content-Location matching the target URI. Reuse is limited to later GET/HEAD requests.

Response headers define lifetime and scope.

Cache-Control: max-age, s-maxage, no-cache, no-store, private, must-revalidate to set lifetime and revalidation rules.
ETag/Last-Modified: tags or timestamps for revalidation. Use with conditional requests.
Vary: identify request headers used to select the representation, such as Accept-Language. It does not replace access control or private.
Expires: a freshness deadline. max-age takes precedence; s-maxage takes precedence for shared caches.

Allowed by spec, but only when conditions are explicit. Otherwise, assume no caching.

Explicit freshness, such as max-age or Expires, and Content-Location equal to the POST target URI are required.
public alone does not provide freshness. General storage requirements, including status and no-store restrictions, still apply.
The stored response can serve later GET/HEAD requests, but must not satisfy a later POST request.
Use private when bodies contain user-specific data to keep them out of shared caches.

Set Cache-Control: no-store for sensitive responses like token issuance.
Shared caches normally cannot reuse responses to requests with Authorization. public, s-maxage, and must-revalidate allow exceptions (RFC 9111 §3.5). Do not apply them casually to personalized responses.

Lean on conditional requests for GET/HEAD to avoid full downloads.

Emit ETag and honor If-None-Match to return 304 when unchanged.
no-store prohibits storage. no-cache permits storage but requires validation before reuse. max-age=0 does not prohibit storage either.
Changing an ETag or origin headers does not notify caches that still hold fresh responses. Plan an acceptable freshness lifetime; use a CDN purge mechanism where necessary.

Separate permission to store from conditions for reuse. Continue with conditional requests and ETag or review the properties of HTTP methods.

< Conditional requests and ETag CORS preflight and OPTIONS >