Decision guide · POST responses · 10 Oct 2026
When can a POST response be cached?
Separate the narrow permission to reuse a POST response for a later retrieval from the forwarding and invalidation rules for an unsafe POST.
The short answer
A response to POST is eligible for caching under the POST-specific rule only when it has explicit freshness information and a Content-Location whose value is the same as the POST target URI. If stored and otherwise reusable, it may answer a later GET or HEAD for that URI—not a later POST. Eligibility does not make a cache store or reuse it.
Two different cache rules
Can this POST response serve a later retrieval?
- Response supplies explicit freshness, such as
max-ageorExpires. Content-Locationequals the POST request's target URI.- General storage, matching, and freshness rules also permit use.
Possible reuse: later GET or HEAD. Not a later POST.
What must a cache do with the unsafe POST?
- Write it through: forward it and receive a corresponding response before replying.
- After a 2xx or 3xx response, invalidate stored response(s) for the target URI.
- This applies only to caches the request traverses—not every cache.
This invalidation rule does not say whether the cache then stores the new POST response.
Do not collapse eligibility into a cache hit
A response can meet the POST-specific conditions and still not be stored. HTTP caching is optional; a cache may decline storage, and other rules such as no-store, method support, or response matching still matter. A successful POST also does not issue a global purge: RFC invalidation is limited to caches traversed by that request.
Different use case: memoizing repeated POST bodies
If “cache POST” means reusing a result for repeated body-bearing requests, that is a separate application/edge cache-key design—not the RFC permission above. Cloudflare’s official Workers example uses custom logic: it hashes the POST body into a synthetic GET key for the Cache API, then fetches the original POST on a miss. This example is not generic HTTP cache support and does not establish a safe key for every operation.
A qualifying header shape
POST /preview
HTTP/1.1 200 OK
Cache-Control: max-age=60
Content-Location: https://example.invalid/previewFor target https://example.invalid/preview, the response supplies explicit freshness and the same-target Content-Location. It is eligible for possible later GET/HEAD reuse if stored and otherwise reusable. The reserved .invalid example was not sent over a network.
Read the full report
The dated report includes the expected-only case matrix, failed-condition examples, invalidation scope, and the primary RFC references: POST response caching and unsafe-request invalidation →
For request-side directives such as no-cache and only-if-cached, see Request cache controls. Request preferences do not change the response-side POST conditions.