Parses Cache-Control and other headers. Helps building correct HTTP caches and proxies. 

Parses Cache-Control and other headers. Helps building correct HTTP caches and proxies

kornel

http-cache-semantics

  "description": "Parses Cache-Control and other headers. Helps building correct HTTP caches and proxies",

  "repository": "https://github.com/pornel/http-cache-semantics.git",

    "compile": "babel -d node4/ index.js; babel -d node4/test test",

    "test": "npm run compile; mocha node4/test"

  "author": "Kornel Lesiński <kornel@geekhood.net> (https://kornel.ski/)",

# Can I cache this? [![Build Status](https://travis-ci.org/pornel/http-cache-semantics.svg?branch=master)](https://travis-ci.org/pornel/http-cache-semantics)

`CachePolicy` tells when responses can be reused from a cache, taking into account [HTTP RFC 7234](http://httpwg.org/specs/rfc7234.html) rules for user agents and shared caches. It's aware of many tricky details such as the `Vary` header, proxy revalidation, and authenticated responses.

Cacheability of an HTTP response depends on how it was requested, so both `request` and `response` are required to create the policy.

const policy = new CachePolicy(request, response, options);

    // throw the response away, it's not usable at all

// Cache the data AND the policy object in your cache

// (this is pseudocode, roll your own cache (lru-cache package works))

letsPretendThisIsSomeCache.set(request.url, {policy, response}, policy.timeToLive());

// And later, when you receive a new request:

const {policy, response} = letsPretendThisIsSomeCache.get(newRequest.url);

// It's not enough that it exists in the cache, it has to match the new request, too:

if (policy && policy.satisfiesWithoutRevalidation(newRequest)) {

    // OK, the previous response can be used to respond to the `newRequest`.

    // Response headers have to be updated, e.g. to add Age and remove uncacheable headers.

    response.headers = policy.responseHeaders();

It may be surprising, but it's not enough for an HTTP response to be [fresh](#yo-fresh) to satisfy a request. It may need to match request headers specified in `Vary`. Even a matching fresh response may still not be usable if the new request restricted cacheability, etc.

The key method is `satisfiesWithoutRevalidation(newRequest)`, which checks whether the `newRequest` is compatible with the original request and whether all caching conditions are met.

Request and response must have a `headers` property with all header names in lower case. `url`, `status` and `method` are optional (defaults are any URL, status `200`, and `GET` method).

        'cache-control': 'public, max-age=7234',

    immutableMinTimeToLive: 24*3600*1000, // 24h

If `options.shared` is `true` (default), then the response is evaluated from a perspective of a shared cache (i.e. `private` is not cacheable and `s-maxage` is respected). If `options.shared` is `false`, then the response is evaluated from a perspective of a single-user cache (i.e. `private` is cacheable and `s-maxage` is ignored).

`options.cacheHeuristic` is a fraction of response's age that is used as a fallback cache duration. The default is 0.1 (10%), e.g. if a file hasn't been modified for 100 days, it'll be cached for 100*0.1 = 10 days.

`options.immutableMinTimeToLive` is a number of milliseconds to assume as the default time to cache responses with `Cache-Control: immutable`. Note that [per RFC](http://httpwg.org/http-extensions/immutable.html) these can become stale, so `max-age` still overrides the default.

If `options.ignoreCargoCult` is true, common anti-cache directives will be completely ignored if the non-standard `pre-check` and `post-check` directives are present. These two useless directives are most commonly found in bad StackOverflow answers and PHP's "session limiter" defaults.

Returns `true` if the response can be stored in a cache. If it's `false` then you MUST NOT store either the request or the response.

### `satisfiesWithoutRevalidation(newRequest)`

This is the most important method. Use this method to check whether the cached response is still fresh in the context of the new request.

If it returns `true`, then the given `request` matches the original response this cache policy has been created with, and the response can be reused without contacting the server. Note that the old response can't be returned without being updated, see `responseHeaders()`.

If it returns `false`, then the response may not be matching at all (e.g. it's for a different URL or method), or may require to be refreshed first (see `revalidationHeaders()`).

Returns updated, filtered set of response headers to return to clients receiving the cached response. This function is necessary, because proxies MUST always remove hop-by-hop headers (such as `TE` and `Connection`) and update response's `Age` to avoid doubling cache time.

cachedResponse.headers = cachePolicy.responseHeaders(cachedResponse);

Returns approximate time in *milliseconds* until the response becomes stale (i.e. not fresh).

After that time (when `timeToLive() <= 0`) the response might not be usable without revalidation. However, there are exceptions, e.g. a client can explicitly allow stale responses, so always check with `satisfiesWithoutRevalidation()`.

* [ImageOptim API](https://imageoptim.com/api), [make-fetch-happen](https://github.com/zkat/make-fetch-happen), [cacheable-request](https://www.npmjs.com/package/cacheable-request), [npm/registry-fetch](https://github.com/npm/registry-fetch), [etc.](https://github.com/pornel/http-cache-semantics/network/dependents)

* `Cache-Control` response header with all the quirks.

* Default cacheability of statuses and methods.

* Merging of range requests, If-Range (but correctly supports them as non-cacheable)

* Revalidation of multiple representations

		{
		"name": "http-cache-semantics",
		"version": "3.8.0",
		"version": "3.8.1",
		"description": "Parses Cache-Control and other headers. Helps building correct HTTP caches and proxies",
		@@ -13,5 +13,3 @@ "repository": "https://github.com/pornel/http-cache-semantics.git",
		"files": [
		"node4/index.js",
		"index.js",
		"test"
		"node4/index.js"
		],
		@@ -22,5 +20,5 @@ "author": "Kornel Lesiński <kornel@geekhood.net> (https://kornel.ski/)",
		"babel-cli": "^6.24.1",
		"babel-preset-env": "^1.5.2",
		"babel-preset-env": "^1.6.1",
		"mocha": "^3.4.2"
		}
		}

		@@ -158,2 +158,6 @@ # Can I cache this? [![Build Status](https://travis-ci.org/pornel/http-cache-semantics.svg?branch=master)](https://travis-ci.org/pornel/http-cache-semantics)

		## Used by

		* [ImageOptim API](https://imageoptim.com/api), [make-fetch-happen](https://github.com/zkat/make-fetch-happen), [cacheable-request](https://www.npmjs.com/package/cacheable-request), [npm/registry-fetch](https://github.com/npm/registry-fetch), [etc.](https://github.com/pornel/http-cache-semantics/network/dependents)

		## Implemented
		@@ -173,3 +177,3 @@

		* Range requests, If-Range
		* Merging of range requests, If-Range (but correctly supports them as non-cacheable)
		* Revalidation of multiple representations

New alerts

Improved metrics

Worsened metrics