Struct fastly::cache::core::TransactionLookupBuilder

pub struct TransactionLookupBuilder { /* private fields */ }

A builder-style API for configuring a transactional lookup.

Implementations

impl TransactionLookupBuilder

pub fn header_values<'a>( self, name: impl ToHeaderName, values: impl IntoIterator<Item = &'a HeaderValue> ) -> Self

Sets a multi-value header for this lookup, 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. 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.

pub fn header(self, name: impl ToHeaderName, value: impl ToHeaderValue) -> Self

Sets a single-value header for this lookup, 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. 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.

pub fn execute(self) -> Result<Transaction, CacheError>

Perform the lookup, entering a Transaction.

If the lookup hits an object being provided by another client, this call will block until that client provides the object’s metadata or cancels.

Accessors like Transaction::found() can be used to determine the outcome of the lookup.

pub fn execute_async(self) -> Result<PendingTransaction, CacheError>

Perform the lookup, returning a PendingTransaction.

If the lookup hits an object being provided by another client, this call will not block. Instead, the returned PendingTransaction can be used to wait for the request collapsed lookup to complete. See the documentation of PendingTransaction for more details.