beresp.cacheable
BOOL, can be read and set, but not unset.
Available infetch
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:
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.
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.
Try it out
beresp.cacheable is used in the following code examples. Examples apply VCL to real-world use cases and can be deployed as they are, or adapted for your own service. See the full list of code examples for more inspiration.
Click RUN on a sample below to provision a Fastly service, execute the code on Fastly, and see how the function behaves.
Cache '429' rate-limiter responses per IP
If a backend returns a 429, cache it for the requesting IP but continue to allow other clients to use origin.
Auto retry a secondary backend
If primary backend fails, retry with a different backend without caching the failure or reducing cache efficiency.
