RTIME, can be read and
set, but not
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
Age headers received from the backend. Setting this variable takes precedence over those headers.
Once the TTL is reached, if the object has not been evicted or purged, it will become stale.
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.
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
To do so, whenever you set
beresp.ttl, subtract any existing Age:
set beresp.ttl = 3600s;set beresp.ttl -= std.atoi(beresp.http.Age);
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.