Dynamic Modules HTTP Filter (proto)

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

Note

This extension is functional but has not had substantial production burn time, use only with this caveat.

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 categories:

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

extensions.filters.http.dynamic_modules.v3.DynamicModuleFilter

[extensions.filters.http.dynamic_modules.v3.DynamicModuleFilter proto]

Configuration for the Dynamic Modules HTTP filter. This filter allows loading shared object files that can be loaded via dlopen to extend the HTTP filter chain.

A module can be loaded by multiple HTTP filters; the module is loaded only once and shared across multiple filters.

A dynamic module HTTP filter can opt into being a terminal filter with no upstream by setting terminal_filter to true. A terminal dynamic module can use send_ ABI methods to send response headers, body, and trailers to the downstream.

{
  "dynamic_module_config": {...},
  "filter_name": ...,
  "filter_config": {...},
  "terminal_filter": ...
}
dynamic_module_config

(extensions.dynamic_modules.v3.DynamicModuleConfig) Specifies the shared-object level configuration.

filter_name

(string) The name for this filter configuration.

This can be used to distinguish between different filter implementations inside a dynamic module. For example, a module can have completely different filter implementations. When Envoy receives this configuration, it passes the filter_name to the dynamic module’s HTTP filter config init function together with the filter_config. That way a module can decide which in-module filter implementation to use based on the name at load time.

filter_config

(Any) The configuration for the filter chosen by filter_name.

This is passed to the module’s HTTP filter initialization function. Together with the filter_name, the module can decide which in-module filter implementation to use and fine-tune the behavior of the filter.

For example, if a module has two filter implementations, one for logging and one for header manipulation, filter_name is used to choose either logging or header manipulation. The filter_config can be used to configure the logging level or the header manipulation behavior.

google.protobuf.Struct is serialized as JSON before passing it to the plugin. google.protobuf.BytesValue and google.protobuf.StringValue are passed directly without the wrapper.

# Passing in a string
filter_config:
  "@type": "type.googleapis.com/google.protobuf.StringValue"
  value: hello

# Passing in raw bytes
filter_config:
  "@type": "type.googleapis.com/google.protobuf.BytesValue"
  value: aGVsbG8= # echo -n "hello" | base64
terminal_filter

(bool) If true, the dynamic module is a terminal filter to use without an upstream.

The dynamic module is responsible for creating and sending the response to downstream.

Defaults to false.

extensions.filters.http.dynamic_modules.v3.DynamicModuleFilterPerRoute

[extensions.filters.http.dynamic_modules.v3.DynamicModuleFilterPerRoute proto]

Configuration of the HTTP per-route filter for dynamic modules.

{
  "dynamic_module_config": {...},
  "per_route_config_name": ...,
  "filter_config": {...}
}
dynamic_module_config

(extensions.dynamic_modules.v3.DynamicModuleConfig) Specifies the shared-object level configuration.

per_route_config_name

(string) The name for this filter configuration.

This can be used to distinguish between different filter implementations inside a dynamic module. For example, a module can have completely different filter implementations. When Envoy receives this configuration, it passes the per_route_config_name to the dynamic module’s HTTP per-route filter config init function together with the filter_config. That way a module can decide which in-module filter implementation to use based on the name at load time.

filter_config

(Any) The configuration for the filter chosen by per_route_config_name.

This is passed to the module’s HTTP per-route filter initialization function. Together with the per_route_config_name, the module can decide which in-module filter implementation to use and fine-tune the behavior of the filter on a specific route.

For example, if a module has two filter implementations, one for logging and one for header manipulation, per_route_config_name is used to choose either logging or header manipulation. The filter_config can be used to configure the logging level or the header manipulation behavior.

google.protobuf.Struct is serialized as JSON before passing it to the plugin. google.protobuf.BytesValue and google.protobuf.StringValue are passed directly without the wrapper.

# Passing in a string
filter_config:
  "@type": "type.googleapis.com/google.protobuf.StringValue"
  value: hello

# Passing in raw bytes
filter_config:
  "@type": "type.googleapis.com/google.protobuf.BytesValue"
  value: aGVsbG8= # echo -n "hello" | base64