http-protocol-cache

Posted on Edited on In ,

Overview

The performance of web sites and applications can be significantly improved by reusing previously fetched resources. Web caches reduce latency and network traffic and thus lessen the time needed to display a representation of a resource. By making use of HTTP caching, Web sites become more responsive.

There are several kinds of caches: these can be grouped into two main categories: private or shared caches. A shared cache is a cache that stores responses for reuse by more than one user. A private cache is dedicated to a single user.

Cache what

HTTP caching is optional, but reusing a cached resource is usually desirable. However, common HTTP caches are typically limited to caching responses to GET and may decline other methods. The primary cache key(may have secondary key like Vary header etc) consists of the request method and target URI (oftentimes only the URI is used as only GET requests are caching targets). Common forms of caching entries are:

  • Successful results of a retrieval request: a 200 (OK) response to a GET request containing a resource like HTML documents, images or files.
  • Permanent redirects: a 301 (Moved Permanently) response.
  • Error responses: a 404 (Not Found) result page.
  • Incomplete results: a 206 (Partial Content) response.
  • Responses other than GET if something suitable for use as a cache key is defined.

A cache entry might also consist of multiple stored responses differentiated by a secondary key, if the request is target of content negotiation.

Cache-Control header

The Cache-Control HTTP/1.1 general-header field is used to specify directives for caching mechanisms in both requests and responses.

No caching

Cache-Control: no-store

Cache but revalidate

Cache-Control: no-cache

Validation

When using the “must-revalidate” directive, the cache must verify the status of the stale resources before using it and expired ones should not be used

Cache-Control: must-revalidate

Expiration
The most important directive here is “max-age=<seconds>“ which is the maximum amount of time a resource will be considered fresh. Contrary to Expires, this directive is relative to the time of the request.

Cache-Control: max-age=600

Freshness

cache should only be updated when client requests the uri(server never notifies client when resource changes), Before this expiration time, the resource is fresh; after the expiration time, the resource is stale. Eviction algorithms often privilege fresh resources over stale resources. Note that a stale resource is ignored ; when the cache receives a request for a stale resource, it forwards this request with a If-None-Match to check if it is in fact still fresh. If so, the server returns a 304 (Not Modified) header without sending the body of the requested resource, saving some bandwidth.

cache with Vary header

The Vary HTTP response header determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server. without vary header, you can think key as just domain + uri, with vary header, cache key: domain + uri + Vary header.

When a cache receives a request that can be satisfied by a cached response that has a Vary header field, it must not use that cached response unless all header fields as nominated by the Vary header match in both the original (cached) request and the new request.