Dynamic Modules Header Formatter (proto)

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

Note

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

This extension is not hardened 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:

extensions.http.header_formatters.dynamic_modules.v3.DynamicModuleHeaderFormatter

[extensions.http.header_formatters.dynamic_modules.v3.DynamicModuleHeaderFormatter proto]

Configuration for the Dynamic Modules HTTP/1 header formatter. This extension allows loading shared object files via dlopen to decide the casing of header keys written on the wire, which is what the preserve case formatter does with a fixed policy. See the header casing configuration guide for how to select a stateful formatter.

This extension only affects HTTP/1 traffic: HTTP/2 and HTTP/3 require lower-cased header keys.

{
  "dynamic_module_config": {...},
  "header_formatter_name": ...,
  "header_formatter_config": {...}
}
dynamic_module_config

(extensions.dynamic_modules.v3.DynamicModuleConfig, REQUIRED) Specifies the shared-object level configuration. This field is required.

Only sources that are available synchronously are supported, i.e. name, module.local, and a module.remote that is already present in the on-disk cache. A remote source that would need to be fetched is rejected, since the codec must be able to format headers for the first message the connection serves.

header_formatter_name

(string) The name for this header formatter configuration. If not specified, defaults to an empty string.

This can be used to distinguish between different header formatter implementations inside a dynamic module. When Envoy receives this configuration, it passes the header_formatter_name to the dynamic module’s header formatter config init function together with the header_formatter_config. That way a module can decide which in-module implementation to use based on the name at load time.

header_formatter_config

(Any) The configuration for the header formatter chosen by header_formatter_name. If not specified, an empty configuration is passed to the module.

This is passed to the module’s header formatter initialization function. Together with the header_formatter_name, the module can decide which in-module implementation to use and fine-tune its behavior.

google.protobuf.Struct and the value field of xds.type.v3.TypedStruct are serialized as JSON before passing them to the module. google.protobuf.BytesValue and google.protobuf.StringValue are passed directly without the wrapper.

# Passing a JSON struct configuration
header_formatter_config:
  "@type": "type.googleapis.com/google.protobuf.Struct"
  value:
    known_headers:
    - X-Request-ID

# Passing a simple string configuration
header_formatter_config:
  "@type": "type.googleapis.com/google.protobuf.StringValue"
  value: "proper_case"