Acacheable response is an HTTP response that can be cached, that is stored to be retrieved and used later, saving a new request to the server. Not all HTTP responses can be cached; these are the constraints for an HTTP response to be cacheable:

• The method used in the request iscacheable, that is either aGET or aHEAD method. A response to aPOST orPATCH request can also be cached if freshness is indicated and theContent-Location header is set, but this is rarely implemented. For example, Firefox does not support it (Firefox bug 109553). Other methods, likePUT orDELETE are not cacheable and their result cannot be cached.
• The status code of the response isknown by the application caching, and iscacheable. The following status codes are cacheable:200,203,204,206,300,301,404,405,410,414, and501.
• There are no specific headers in the response, likeCache-Control, with values that would prohibit caching.

Note that some requests with non-cacheable responses to a specific URI may invalidate previously cached responses from the same URI. For example, aPUT to/pageX.html will invalidate all cached responses toGET orHEAD requests to/pageX.html.

When both the method of the request and the status of the response are cacheable, the response to the request can be cached:

GET /pageX.html HTTP/1.1(…)200 OK(…)

The response to aPUT request cannot be cached. Moreover, it invalidates cached data for requests to the same URI usingHEAD orGET methods:

PUT /pageX.html HTTP/1.1(…)200 OK(…)

The presence of theCache-Control header with a particular value in the response can prevent caching:

GET /pageX.html HTTP/1.1(…)200 OKCache-Control: no-cache(…)

See also

• Details aboutmethods and caching are provided in the HTTP specification.
• Description of common cacheable methods:GET,HEAD
• Description of common non-cacheable methods:PUT,DELETE, oftenPOST