---
title: beresp.cacheable
summary: null
url: >-
  https://www.fastly.com/documentation/reference/vcl/variables/backend-response/beresp-cacheable
---

**Type:** BOOL  
**Access:** can be read and set, but not unset

**Available in:** fetch

Whether or not the object is cacheable. Setting to `true` will cause otherwise
uncacheable responses to be cached. Setting to `false` will cause otherwise
cacheable responses to be passed.

The default value of this variable is determined by the HTTP status code of the response.  The following response statuses will cause `beresp.cacheable` to be set to `true` at the start of the `vcl_fetch` subroutine.  Any other response status will result in `beresp.cacheable` being set to `false`.

| Status | Description                   |
| ------ | ----------------------------- |
| 200    | OK                            |
| 203    | Non-Authoritative Information |
| 300    | Multiple Choices              |
| 301    | Moved Permanently             |
| 302    | Moved Temporarily             |
| 404    | Not Found                     |
| 410    | Gone                          |

The behavior for a response with the HTTP status code `206` (Partial Content) depends on whether Segmented Caching is enabled.  To enable Segmented Caching, set `req.enable_segmented_caching` to `true` in `vcl_recv`.

If Segmented Caching is enabled, then a backend response with status code `206` will cause `beresp.cacheable` to be set to `true` at the start of the `vcl_fetch` subroutine.  If it is not enabled, then a backend response with status code `206` will cause `beresp.cacheable` to be set to `false` at the start of the `vcl_fetch` subroutine.

A common pattern is to override this behavior to allow all 2XX responses not included in the table above to be cacheable:

```vcl context="vcl_fetch { ... }"
if (beresp.status >= 200 && beresp.status < 300) {
  set beresp.cacheable = true;
}
```

For more details on how Fastly determines the eligibility of content for caching, see our guide to [cache freshness and TTLs](https://www.fastly.com/documentation/guides/concepts/edge-state/cache/cache-freshness/).

## Effects on request collapsing

If `beresp.cacheable` is `false`, the object will not be saved to cache, even if execution of the subroutine ends in `return(deliver)`.  A _hit-for-pass_ object will also not be created.  Any secondary requests waiting on this response as a result of request collapsing will therefore be dequeued but are liable to form another queue immediately, and be sent to origin consecutively.