.. _envoy_v3_api_file_envoy/extensions/matching/input_matchers/dynamic_modules/v3/dynamic_modules.proto:

Dynamic Modules Input Matcher (proto)
=====================================

.. _extension_envoy.matching.matchers.dynamic_modules:

This extension has the qualified name ``envoy.matching.matchers.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:


  - :ref:`envoy.matching.input_matchers <extension_category_envoy.matching.input_matchers>`



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



  - :ref:`type.googleapis.com/envoy.extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher <envoy_v3_api_msg_extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher>`







.. _envoy_v3_api_msg_extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher:

extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher
--------------------------------------------------------------------------


:repo:`[extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher proto] <api/envoy/extensions/matching/input_matchers/dynamic_modules/v3/dynamic_modules.proto#L27>`

Configuration for the Dynamic Modules Input Matcher. This matcher allows loading shared object
files via ``dlopen`` to implement custom matching logic in dynamic modules (e.g. Rust, Go).

A module can implement arbitrary matching logic by examining request headers and other HTTP
attributes during the match evaluation. This is useful for scenarios that require complex
matching beyond what built-in matchers provide, such as JWT/OAuth token analysis, custom
routing decisions, or integration with external data sources.



.. code-block:: json
  :force:

  {
    "dynamic_module_config": {...},
    "matcher_name": ...,
    "matcher_config": {...}
  }

.. _envoy_v3_api_field_extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher.dynamic_module_config:


dynamic_module_config
  (:ref:`extensions.dynamic_modules.v3.DynamicModuleConfig <envoy_v3_api_msg_extensions.dynamic_modules.v3.DynamicModuleConfig>`, *REQUIRED*) Specifies the shared-object level configuration. This field is required.


.. _envoy_v3_api_field_extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher.matcher_name:


matcher_name
  (`string <https://developers.google.com/protocol-buffers/docs/proto#scalar>`_) The name for this matcher configuration. If not specified, defaults to an empty string.

  This can be used to distinguish between different matcher implementations inside a dynamic
  module. For example, a module can have completely different matcher implementations (e.g.,
  OAuth token matcher, geo-IP matcher). When Envoy receives this configuration, it passes
  the ``matcher_name`` to the dynamic module's matcher config init function together with the
  ``matcher_config``. That way a module can decide which in-module matcher implementation to
  use based on the name at load time.


.. _envoy_v3_api_field_extensions.matching.input_matchers.dynamic_modules.v3.DynamicModuleMatcher.matcher_config:


matcher_config
  (`Any <https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#any>`_) The configuration for the matcher chosen by ``matcher_name``. If not specified, an empty
  configuration is passed to the module.

  This is passed to the module's matcher initialization function. Together with the
  ``matcher_name``, the module can decide which in-module matcher implementation to use and
  fine-tune the behavior of the matcher.

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