---
title: About cache control headers
summary: null
url: >-
  https://www.fastly.com/documentation/guides/full-site-delivery/caching/about-cache-control-headers
---


You can use cache control headers in your origin's responses to set policies that determine the maximum amount of time that content may be cached by Fastly. Fastly looks for caching information in each of these headers as described in our documentation on [cache freshness](/guides/concepts/cache/cache-freshness) in order of preference:

1. `Surrogate-Control:`
1. `Cache-Control: s-maxage`
1. `Cache-Control: max-age`
1. `Expires:`

## Surrogate headers

Surrogate headers provide a specific cache policy for CDN caches like Fastly. `Surrogate-Control` accepts many of the same values as `Cache-Control`, plus some other more esoteric ones.

One use of this technique is to provide conservative cache interactions to the browser (for example, `Cache-Control: no-cache`). This causes the browser to re-validate with Fastly on every request for the content, ensuring users get the freshest possible content. Simultaneously, your origin can send a `Surrogate-Control` header with a longer `max-age` that lets Fastly handle most of the browser traffic, only passing requests to your origin when Fastly's cache expires.

With Fastly, one of the most useful Surrogate headers is `Surrogate-Key`. When Fastly processes a request and sees a `Surrogate-Key` header in your origin's response, it uses the space-separated value as a list of tags to associate with the request URL in the cache. Combined with [Fastly's Purge API](/reference/api/purging/), an entire collection of URLs can be expired from the cache in one API call (and typically happens in around 1ms).

## `Cache-Control` directives

Only the following `Cache-Control` response directives, as defined by [section 5.2.2 of RFC 9111](https://www.rfc-editor.org/rfc/rfc9111.html#section-5.2.2), influence Fastly's caching:

* `Cache-Control: public` - Any cache can store a copy of the content. You don't need to add the `public` directive to a response as most content is cacheable by default.
* `Cache-Control: private` - Don't store. This is intended for user-specific content.
* `Cache-Control: max-age=[seconds]` - Caches can store this content for *n* seconds.
* `Cache-Control: s-maxage=[seconds]` - Same as max-age but applies specifically to CDN caches like Fastly.

All other `Cache-Control` directives are ignored and will __not__ influence Fastly's caching, but will be passed through to the browser. Directives ignored by Fastly include, but are not limited to, `Cache-Control: no-cache`, `Cache-Control: no-store`, and `Cache-Control: must-revalidate`. 

For more in-depth information about how Fastly responds to cache control headers and how these headers interact with `Expires` and `Surrogate-Control`, check out our documentation on [HTTP caching semantics](/guides/concepts/cache/cache-freshness).

## `Authorization` header

Requests with an `Authorization` header are considered cacheable by default. To prevent requests with an `Authorization` header from receiving a cached response, refer to the documentation on [HTTP caching semantics](/guides/concepts/cache/cache-freshness/#divergences-from-rfc-9111).

## `Expires` header

The `Expires` header tells caches how long to store a piece of content. The downside is that it's a static date, and if your origin doesn't update it, the date will pass and browsers will start requesting that resource from Fastly every time.

Fastly will respect the `Expires` header value only if your origin doesn't send `Surrogate-Control` or `Cache-Control` headers in the response.