HTTP Cache Filter V2 (proto)

Warning

This API feature is currently work-in-progress. API features marked as work-in-progress are not considered stable, are not covered by the threat model, are not supported by the security team, and are subject to breaking changes. Do not use this feature without understanding each of the previous points.

extensions.filters.http.cache_v2.v3.CacheV2Config

[extensions.filters.http.cache_v2.v3.CacheV2Config proto]

This extension has the qualified name envoy.filters.http.cache_v2

Note

This extension is work-in-progress. Functionality is incomplete and it is not intended for production use.

This extension has an unknown security posture and should only be used in deployments where both the downstream and upstream are trusted.

Tip

This extension extends and can be used with the following extension category:

This extension must be configured with one of the following type URLs:

{
  "typed_config": {...},
  "disabled": {...},
  "ignore_request_cache_control_header": ...,
  "override_upstream_cluster": ...
}
typed_config

(Any) Config specific to the cache storage implementation. Required unless disabled is true.

Tip

This extension category has the following known extensions:

disabled

(BoolValue) When true, the cache filter is a no-op filter.

Possible use-cases for this include: - Turning a filter on and off with ECDS.

ignore_request_cache_control_header

(bool) By default, a cache-control: no-cache or pragma: no-cache header in the request causes the cache to validate with its upstream even if the lookup is a hit. Setting this to true will ignore these headers.

override_upstream_cluster

(string) If this is set, requests sent upstream to populate the cache will go to the specified cluster rather than the cluster selected by the vhost and route.

If you have actions to be taken by the router filter - either upstream_http_filters or one of the RouteConfiguration actions such as response_headers_to_add - then the cache’s side-channel going directly to the routed cluster will bypass these actions. You can set override_upstream_cluster to an internal listener which duplicates the relevant RouteConfiguration, to replicate the desired behavior on the side-channel upstream request issued by the cache.

This is a workaround for implementation constraints which it is hoped will at some point become unnecessary, then unsupported and this field will be removed.