beresp.ttl

RTIME, can be read and set, but not unset.

Available infetch

Maximum amount of time for which the object will be considered fresh in the cache. By default, the value of beresp.ttl will be parsed from the Surrogate-Control, Cache-Control, Expires, and Age headers received from the backend. Setting this variable takes precedence over those headers.

Conversely, setting caching headers in vcl_fetch will not affect beresp.ttl because the value of beresp.ttl is derived from the headers only once, before vcl_fetch is executed.

Once the TTL is reached, if the object has not been evicted or purged, it will become stale.

Multi level caching with Age

If you have multiple levels of caching, setting beresp.ttl explicitly can result in content staying in cache longer than you expect. This often occurs when making use of Fastly's shielding feature or if your backend server is serving content that has already spent time in a cache.

The Age header is used by servers to communicate to a client how long the content has spent in cache, and if the client is also a cache, it can take this into account when calculating a TTL. This behavior is built into the way Fastly calculates cache TTL by default. However, if you set beresp.ttl explicitly, you must do this calculation if you want to respect the Age header.

To do so, whenever you set beresp.ttl, subtract any existing Age:

sub vcl_fetch { ... }
Fastly VCL
set beresp.ttl = 3600s;
set beresp.ttl -= std.atoi(beresp.http.Age);

Try it out

beresp.ttl 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.

Override TTLs based on content type

Set TTLs at the edge based on the type of resource. Better done at origin, but this can be a great 'quick fix' or a solution if you don't control the origin.

Serve stale content from cache while origins are offline

Deal with all potential scenarios for using stale content to satisfy requests when origin is unhealthy or misbehaving.

User contributed notes

BETA

Do you see an error in this page? Do you have an interesting use case, example or edge case people should know about? Share your knowledge and help people who are reading this page! (Comments are moderated; for support, please contact Fastly support)