Repository: envoyproxy/envoy
File: api/envoy/extensions/filters/http/dynamic_modules/v3/dynamic_modules.proto (Protocol Buffers)

Code before:
syntax = "proto3";

package envoy.extensions.filters.http.dynamic_modules.v3;

import "envoy/extensions/dynamic_modules/v3/dynamic_modules.proto";

import "google/protobuf/any.proto";

import "udpa/annotations/status.proto";

option java_package = "io.envoyproxy.envoy.extensions.filters.http.dynamic_modules.v3";
option java_outer_classname = "DynamicModulesProto";
option java_multiple_files = true;
option go_package = "github.com/envoyproxy/go-control-plane/envoy/extensions/filters/http/dynamic_modules/v3;dynamic_modulesv3";
option (udpa.annotations.file_status).package_version_status = ACTIVE;

// [#protodoc-title: HTTP filter for dynamic modules]
// [#extension: envoy.filters.http.dynamic_modules]

// Configuration of the HTTP filter for dynamic modules. This filter allows loading shared object files
// that can be loaded via dlopen by the HTTP filter.
//
// A module can be loaded by multiple HTTP filters, hence the program can be structured in a way that
// the module is loaded only once and shared across multiple filters providing multiple functionalities.
//
// A dynamic module can opt into being a terminal filter with no upstream by setting ``terminal_filter`` to
// true in the configuration. A terminal dynamic module can use ``send_`` ABI methods to send response headers,
// body and trailers to the downstream.
message DynamicModuleFilter {
  // Specifies the shared-object level configuration.
  envoy.extensions.dynamic_modules.v3.DynamicModuleConfig dynamic_module_config = 1;

  // 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.
  string filter_name = 2;

  // 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.
  //

Review comment (suggestion):
We are clarifying that multiple filters can exist in a module above, so let's do so here as well

```suggestion
// A dynamic module HTTP filter can opt into being a terminal filter with no upstream by setting ``terminal_filter`` to
```

Code after:
syntax = "proto3";

package envoy.extensions.filters.http.dynamic_modules.v3;

import "envoy/extensions/dynamic_modules/v3/dynamic_modules.proto";

import "google/protobuf/any.proto";

import "udpa/annotations/status.proto";

option java_package = "io.envoyproxy.envoy.extensions.filters.http.dynamic_modules.v3";
option java_outer_classname = "DynamicModulesProto";
option java_multiple_files = true;
option go_package = "github.com/envoyproxy/go-control-plane/envoy/extensions/filters/http/dynamic_modules/v3;dynamic_modulesv3";
option (udpa.annotations.file_status).package_version_status = ACTIVE;

// [#protodoc-title: HTTP filter for dynamic modules]
// [#extension: envoy.filters.http.dynamic_modules]

// Configuration of the HTTP filter for dynamic modules. This filter allows loading shared object files
// that can be loaded via dlopen by the HTTP filter.
//
// A module can be loaded by multiple HTTP filters, hence the program can be structured in a way that
// the module is loaded only once and shared across multiple filters providing multiple functionalities.
//
// A dynamic module HTTP filter can opt into being a terminal filter with no upstream by setting ``terminal_filter`` to
// true in the configuration. A terminal dynamic module can use ``send_`` ABI methods to send response headers,
// body and trailers to the downstream.
message DynamicModuleFilter {
  // Specifies the shared-object level configuration.
  envoy.extensions.dynamic_modules.v3.DynamicModuleConfig dynamic_module_config = 1;

  // 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.
  string filter_name = 2;

  // 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.
  //