HTTP Caching

Caching is a technique used in HTTP to store a copy of a given resource and serving it back when requested. Caching allows efficient reuse of the previously retrieved or computed data.

How it works


Cache stores data in fast access hardware such as random access memory (RAM). A cache storing of data is typically temporary, unlike database data that are complete and durable.

The data retrieval performance reduces the need to access the underlying slower storage layer.

About Caches


Caches can be private and public. Public cache stores responses to several users and they are also called shared proxy caches. A private browser cache serves a single user.

The browser has a lot of different types of caches for distinct, specific uses:
  • Image cache - a page-scoped cache that stores decoded image data.
  • Preload cache - like the image cache, is page-scoped and destroyed when the user leaves the page; stores anything that has been preloaded in a Link header.
  • Service worker cache API - origin-scoped; provides a cache back end with a programmable interface.
  • HTTP cache - uses cache headers such as Cache-Control to determine the need and duration for caching; all websites share it.
  • HTTP/2 push cache (or 'H2 push cache') - stores objects that have not been used by the server already but not yet been requested by any page using the connection; destroyed when the connection closes.

Cache Control mechanisms


To determine whether a request can be satisfied using a cached copy of the requested resource, a cache policy specifies client requirements for cache freshness and the server requirements for revalidation.

The freshness of cached entries is based on the location of the requested resource; on time of the resource retrieval, on headers returned with a response and the current time.

HTTP Cache controls caching conditions and duration for both requests and responses using HTTP Headers.

Duration

Cache-Control header with the 'max-age' directive specifies the maximum time for which the caching systems are allowed to cache the response in the number of seconds.

With the 'no-store' directive, Cache-Control prevents storing cache and indicates removing the information after being forwarded.

Expires header defines the time the response is to be expired.

'No-cache' and 'max-age=0' directives of the Cache-Control header mean the resource can be cached but has to be validated first with the origin server. After the response becomes stale, the 'must-revalidate' directive revalidates it.

Validation

For each request, the cache clarifies if the cached response is still valid. ETag and Last-Modified headers can be used to implement the validation model.

An ETag compares two different versions of a resource, and if there are equivalent, 304 status code tells the cache that it can return the cached response.

If-Not-Modified-Since: header or an If-None-Match: header indicates the version of the cache of the client.

The Vary response header defines matching future request headers to choose whether to use a cached response or to request one from the origin server.

The invalidation mechanism acts in case a cached response is associated with the URL that subsequently gets a POST, PUT or DELETE request.

In general, Caching lightens the burden of network operations and reduces bandwidth requirements.

Live Request Example to Prevent Caching Live Request
GET /echo/get/json HTTP/1.1
Host: www.reqbin.com
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0


Live Request Example with Cache-control Header Live Request
GET /echo/get/json HTTP/1.1
Host: reqbin.com
Cache-Control: max-age=3600, public, no-transform