InsertBuilder

Sets the maximum time the cached item may live on a deliver node in a POP.

It is an error for this to be greater than the max age of the cached item.

Begin the insertion, returning a StreamingBody for providing the cached object itself.

For the insertion to complete successfully, the object must be written into the StreamingBody, and then StreamingBody::finish must be called. If the StreamingBody is dropped before calling StreamingBody::finish, the insertion is considered incomplete, and any concurrent lookups that may be reading from the object as it is streamed into the cache may encounter a streaming error.

Sets a single-value header for this insertion, discarding any previous values associated with the header name.

Note: These headers are narrowly useful for implementing cache lookups incorporating the semantics of the HTTP Vary header, but the APIs in this module are not suitable for HTTP caching out-of-the-box. Future SDK releases will contain an HTTP Cache API.

The headers act as additional factors in object selection, and the choice of which headers to factor in is determined during insertion, via e.g. crate::cache::core::InsertBuilder::vary_by. A lookup will succeed when there is at least one cached item that matches lookup's cache key, and all of the lookup's headers included in the cache items' vary_by list match the corresponding headers in that cached item.

A typical example is a cached HTTP response, where the request had an Accept-Encoding header. In that case, the origin server may or may not decide on a given encoding, and whether that same response is suitable for a request with a different (or missing) Accept-Encoding header is determined by whether Accept-Encoding is listed in Vary header in the origin's response.

Sets a multi-value header for this insertion, discarding any previous values associated with the header name.

Note: These headers are narrowly useful for implementing cache lookups incorporating the semantics of the HTTP Vary header, but the APIs in this module are not suitable for HTTP caching out-of-the-box. Future SDK releases will contain an HTTP Cache API.

The headers act as additional factors in object selection, and the choice of which headers to factor in is determined during insertion, via e.g. crate::cache::core::InsertBuilder::vary_by. A lookup will succeed when there is at least one cached item that matches lookup's cache key, and all of the lookup's headers included in the cache items' vary_by list match the corresponding headers in that cached item.

A typical example is a cached HTTP response, where the request had an Accept-Encoding header. In that case, the origin server may or may not decide on a given encoding, and whether that same response is suitable for a request with a different (or missing) Accept-Encoding header is determined by whether Accept-Encoding is listed in Vary header in the origin's response.

Sets the initial age of the cached item, to be used in freshness calculations.

The initial age is Duration::ZERO by default.

Sets the size of the cached item, in bytes, when known prior to actually providing the bytes.

It is preferable to provide a length, if possible. Clients that begin streaming the item's contents before it is completely provided will see the promised length which allows them to, for example, use content-length instead of transfer-encoding: chunked if the item is used as the body of a Request or Response.

Perform this insertion on behalf of another service, using its data store.

Internal / Privileged

This operation is privileged, and attempts to use this functionality without proper privileges will cause errors. If you are interested in having two or more of your services share the same cache, please talk to your Fastly account representative. While we have no plans to offer this ability widely -- this capability is only currently allowed for Fastly-internal services -- we may revisit this decision given sufficient customer input.

Enable or disable PCI/HIPAA-compliant non-volatile caching.

By default, this is false

See the Fastly PCI-Compliant Caching and Delivery documentation for details.

Sets the stale-while-revalidate period for the cached item, which is the time for which the item can be safely used despite being considered stale.

Having a stale-while-revalidate period provides a signal that the cache should be updated (or its contents otherwise revalidated for freshness) asynchronously, while the stale cached item continues to be used, rather than blocking on updating the cached item. The methods Found::is_usable and Found::is_stale can be used to determine the current state of a found item.

The stale-while-revalidate period is Duration::ZERO by default.

Sets the surrogate keys that can be used for purging this cached item.

Surrogate key purges are the only means to purge specific items from the cache. At least one surrogate key must be set in order to remove an item without performing a purge-all, waiting for the item's TTL to elapse, or overwriting the item with crate::cache::core::insert().

Surrogate keys must contain only printable ASCII characters (those between 0x21 and 0x7E, inclusive). Any invalid keys will be ignored.

See the Fastly surrogate keys guide for details.

Sets the list of headers that must match when looking up this cached item.

Note: These headers are narrowly useful for implementing cache lookups incorporating the semantics of the HTTP Vary header, but the APIs in this module are not suitable for HTTP caching out-of-the-box. Future SDK releases will contain an HTTP Cache API.

The headers act as additional factors in object selection, and the choice of which headers to factor in is determined during insertion, via e.g. crate::cache::core::InsertBuilder::vary_by. A lookup will succeed when there is at least one cached item that matches lookup's cache key, and all of the lookup's headers included in the cache items' vary_by list match the corresponding headers in that cached item.

A typical example is a cached HTTP response, where the request had an Accept-Encoding header. In that case, the origin server may or may not decide on a given encoding, and whether that same response is suitable for a request with a different (or missing) Accept-Encoding header is determined by whether Accept-Encoding is listed in Vary header in the origin's response.