This plugin provides a reverse proxy cache implementation for Kong. It caches response entities based on configurable response code and content type, as well as request method. It can cache per-Consumer or per-API. Cache entities are stored for a configurable period of time, after which subsequent requests to the same resource will re-fetch and re-store the resource. Cache entities can also be forcefully purged via the Admin API prior to their expiration time.
Configuration Reference
This plugin is compatible with DB-less mode.
In DB-less mode, you configure Kong Gateway declaratively. Therefore, the Admin API is mostly read-only. The only tasks it can perform are all related to handling the declarative config, including:
- Setting a target's health status in the load balancer
- Validating configurations against schemas
- Uploading the declarative configuration using the
/config
endpoint
Example plugin configuration
Parameters
Here's a list of all the parameters which can be used in this plugin's configuration:
Form Parameter | Description |
---|---|
name
required Type: string |
The name of the plugin, in this case proxy-cache-advanced . |
service.name or service.id
Type: string |
The name or ID of the service the plugin targets.
Set one of these parameters if adding the plugin to a service through the top-level /plugins endpoint.
Not required if using /services/SERVICE_NAME|SERVICE_ID/plugins . |
route.name or route.id
Type: string |
The name or ID of the route the plugin targets.
Set one of these parameters if adding the plugin to a route through the top-level /plugins endpoint.
Not required if using /routes/ROUTE_NAME|ROUTE_ID/plugins . |
consumer.name or consumer.id
Type: string |
The name or ID of the consumer the plugin targets.
Set one of these parameters if adding the plugin to a consumer through the top-level /plugins endpoint.
Not required if using /consumers/CONSUMER_NAME|CONSUMER_ID/plugins . |
enabled
Type: boolean Default value: true |
Whether this plugin will be applied. |
config.response_code
required Type: array of type integer Default value: 200, 301, 404
|
Upstream response status code considered cacheable. The integers must be a value between 100 and 900. |
config.request_method
required Type: array of string elements Default value: ["GET","HEAD"]
|
Downstream request methods considered cacheable. Available options: |
config.content_type
required Type: array of string elements Default value: text/plain, application/json
|
Upstream response content types considered cacheable. The plugin performs an exact match against each specified value; for example, if the upstream is expected to respond with a |
config.vary_headers
optional Type: array of string elements |
Relevant headers considered for the cache key. If undefined, none of the headers are taken into consideration. |
config.vary_query_params
optional Type: array of string elements |
Relevant query parameters considered for the cache key. If undefined, all params are taken into consideration. |
config.cache_ttl
Type: integer Default value: 300
|
TTL in seconds of cache entities. |
config.cache_control
required Type: boolean Default value: false
|
When enabled, respect the Cache-Control behaviors defined in RFC7234. |
config.storage_ttl
optional Type: integer |
Number of seconds to keep resources in the storage backend. This value is independent
of |
config.strategy
required Type: string |
The backing data store in which to hold cache entities. Accepted values are: |
config.memory.dictionary_name
required Type: string Default value: kong_db_cache
|
The name of the shared dictionary in which to hold cache entities when the memory strategy is selected. Note that this dictionary currently must be defined manually in the Kong Nginx template. |
config.redis.host
semi-optional Type: string |
Host to use for Redis connection when the redis strategy is defined. |
config.redis.port
semi-optional Type: integer Default value: 6379
|
Port to use for Redis connections when the |
config.redis.ssl
optional Type: boolean Default value: false
|
If set to Note: This parameter is only available for Kong Gateway versions 2.2.x and later. |
config.redis.ssl_verify
optional Type: boolean Default value: false
|
If set to Note: This parameter is only available for Kong Gateway versions 2.2.x and later. |
config.redis.server_name
optional Type: string |
Specifies the server name for the new TLS extension Server Name Indication (SNI) when connecting over SSL. Note: This parameter is only available for Kong Gateway versions 2.2.x and later. |
config.redis.timeout
semi-optional Type: number Default value: 2000
|
Connection timeout to use for Redis connection when the |
config.redis.password
semi-optional Type: string |
Password to use for Redis connection when the This field is referenceable, which means it can be securely stored as a secret in a vault. References must follow a specific format. |
config.redis.database
semi-optional Type: integer Default value: 0
|
Database to use for Redis connection when the |
config.redis.sentinel_master
semi-optional Type: string |
Sentinel master to use for Redis connection when the |
config.redis.sentinel_username
semi-optional Type: string |
Sentinel username to authenticate with a Redis Sentinel instance. If undefined, ACL authentication will not be performed. This requires Redis v6.2.0+. This field is referenceable, which means it can be securely stored as a secret in a vault. References must follow a specific format. |
config.redis.sentinel_password
semi-optional Type: string |
Sentinel password to authenticate with a Redis Sentinel instance. If undefined, no AUTH commands are sent to Redis Sentinels. This field is referenceable, which means it can be securely stored as a secret in a vault. References must follow a specific format. |
config.redis.sentinel_role
semi-optional Type: string |
Sentinel role to use for Redis connections when the |
config.redis.sentinel_addresses
semi-optional Type: array of string elements |
Sentinel addresses to use for Redis connections when the |
config.redis.cluster_addresses
semi-optional Type: array of string elements |
Cluster addresses to use for Redis connection when the |
config.redis.keepalive_backlog
optional Type: integer |
If specified, limits the total number of opened connections for a pool. If the
connection pool is full, all connection queues beyond the maximum limit go into
the backlog queue. Once the backlog queue is full, subsequent connect operations
will fail and return |
config.redis.keepalive_pool
optional Type: string Default value: generated from string template
|
The custom name of the connection pool. If not specified, the connection pool
name is generated from the string template |
config.redis.keepalive_pool_size
optional Type: integer Default value: 30
|
The size limit for every cosocket connection pool associated with every remote
server, per worker process. If no |
config.bypass_on_err
optional Type: boolean Default value: false
|
Unhandled errors while trying to retrieve a cache entry (such as redis down) are resolved with |
content_type
parameter requires
an exact match. For example, if your Upstream expects
application/json; charset=utf-8
and the
config.content_type
value is only application/json
(a partial match), then the proxy cache is bypassed.
Strategies
kong-plugin-enterprise-proxy-cache
is designed to support storing proxy cache data in different backend formats.
Currently, the following strategies are provided:
memory
: Alua_shared_dict
. Note that the default dictionary,kong_db_cache
, is also used by other plugins and elements of Kong to store unrelated database cache entities. Using this dictionary is an easy way to bootstrap the proxy-cache-advanced plugin, but it is not recommended for large-scale installations as significant usage will put pressure on other facets of Kong’s database caching operations. It is recommended to define a separatelua_shared_dict
via a custom Nginx template at this time.redis
: Supports Redis and Redis Sentinel deployments.
Cache Key
Kong keys each cache elements based on the request method, the full client request (e.g., the request path and query parameters), and the UUID of either the API or Consumer associated with the request. This also implies that caches are distinct between APIs and/or Consumers. Currently the cache key format is hard-coded and cannot be adjusted. Internally, cache keys are represented as a hexadecimal-encoded MD5 sum of the concatenation of the constituent parts calculated as follows:
key = md5(UUID | method | request)
Where method
is defined via the OpenResty ngx.req.get_method()
call, and request
is defined via the Nginx $request
variable.
Kong will return the cache key associated with a given request as the X-Cache-Key
response header.
It is also possible to precalculate the cache key for a given request as noted above.
Cache Control
When the cache_control
configuration option is enabled, Kong will respect request and response
Cache-Control headers as defined by RFC7234, with a few exceptions:
- Cache revalidation is not yet supported, and so directives such as
proxy-revalidate
are ignored. - Similarly, the behavior of
no-cache
is simplified to exclude the entity from being cached entirely. - Secondary key calculation via
Vary
is not yet supported.
Cache Status
Kong identifies the status of the request’s proxy cache behavior via the X-Cache-Status
header. There are several possible values for this header:
Miss
: The request could be satisfied in cache, but an entry for the resource was not found in cache, and the request was proxied upstream.Hit
: The request was satisfied and served from cache.Refresh
: The resource was found in cache, but could not satisfy the request, due to Cache-Control behaviors or reaching its hard-coded cache_ttl threshold.Bypass
: The request could not be satisfied from cache based on plugin configuration.
Storage TTL
Kong can store resource entities in the storage engine longer than the prescribed cache_ttl
or Cache-Control
values indicate.
This allows Kong to maintain a cached copy of a resource past its expiration, which in turn allows clients capable
of using max-age
and max-stale
headers to request stale copies of data if necessary.
Upstream Outages
Due to an implementation in Kong’s core request processing model, at this point,
the proxy-cache-advanced plugin cannot be used to serve stale cache data when an upstream is unreachable.
To equip Kong to serve cache data in place of returning an error when an upstream is unreachable,
we recommend defining a very large storage_ttl
(on the order of hours or days) in order to keep stale data
in the cache. In the event of an upstream outage, stale data can be considered fresh
by increasing the cache_ttl
plugin configuration value. By doing so, data that
would have previously been considered stale is now served to the client, before Kong attempts to connect to a failed upstream service.
Admin API
This plugin provides several endpoints to managed cache entities. These endpoints are assigned to the proxy-cache-advanced
RBAC resource.
The following endpoints are provided on the Admin API to examine and purge cache entities:
Retrieve a Cache Entity
Two separate endpoints are available: one to look up a known plugin instance, and another that searches all proxy-cache-advanced plugins data stores for the given cache key. Both endpoints have the same return value.
Endpoint
Attributes | Description |
---|---|
plugin_id |
The UUID of the proxy-cache-advanced plugin |
cache_id |
The cache entity key as reported by the X-Cache-Key response header |
Endpoint
Attributes | Description |
---|---|
cache_id |
The cache entity key as reported by the X-Cache-Key response header |
Response
If the cache entity exists
HTTP 200 OK
If the entity with the given key does not exist
HTTP 400 Not Found
Delete a Cache Entity
Two separate endpoints are available: one to look up a known plugin instance, and another that searches all proxy-cache-advanced plugins data stores for the given cache key. Both endpoints have the same return value.
Endpoint
Attributes | Description |
---|---|
plugin_id |
The UUID of the proxy-cache-advanced plugin |
cache_id |
The cache entity key as reported by the X-Cache-Key response header |
Endpoint
Attributes | Description |
---|---|
cache_id |
he cache entity key as reported by the X-Cache-Key response header |
Response
If the cache entity exists:
HTTP 204 No Content
If the entity with the given key does not exist:
HTTP 400 Not Found
Purge All Cache Entities
Endpoint
Response
HTTP 204 No Content
Note that this endpoint purges all cache entities across all proxy-cache-advanced
plugins.
Changelog
Kong Gateway 3.1.x
- Added support for integrating with redis clusters using the
config.redis.cluster_addresses
configuration parameter.
Kong Gateway 2.8.x
-
Added the
redis.sentinel_username
andredis.sentinel_password
configuration parameters. -
The
redis.password
,redis.sentinel_username
, andredis.sentinel_password
configuration fields are now marked as referenceable, which means they can be securely stored as secrets in a vault. References must follow a specific format. -
Fixed plugin versions in the documentation. Previously, the plugin versions were labelled as
1.3-x
and2.2.x
. They are now updated to align with the plugin’s actual versions,0.4.x
and0.5.x
.