Envoy Header-To-Metadata Filter

  • v3 API reference

  • This filter should be configured with the name envoy.filters.http.header_to_metadata.

This filter is configured with rules that will be matched against requests and responses. Each rule has either a cookie or a header and can be triggered either when the header or cookie is present or missing.

When a rule is triggered, dynamic metadata will be added based on the configuration of the rule. If the header or cookie is present, it’s value is extracted and used along with the specified key as metadata. If the header or cookie is missing, on missing case is triggered and the value specified is used for adding metadata.

The metadata can then be used for load balancing decisions, consumed from logs, etc.

A typical use case for this filter is to dynamically match requests with load balancer subsets. For this, a given header’s value would be extracted and attached to the request as dynamic metadata which would then be used to match a subset of endpoints.

Example

A sample filter configuration to route traffic to endpoints based on the presence or absence of a version header could be:

  1. http_filters:
  2. - name: envoy.filters.http.header_to_metadata
  3. typed_config:
  4. "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
  5. request_rules:
  6. - header: x-version
  7. on_header_present:
  8. metadata_namespace: envoy.lb
  9. key: version
  10. type: STRING
  11. on_header_missing:
  12. metadata_namespace: envoy.lb
  13. key: default
  14. value: 'true'
  15. type: STRING
  16. remove: false

As with headers, the value of the specified cookie will be extracted from the request and added as metadata with the key specified. Removing a cookie when a rule matches is unsupported.

  1. http_filters:
  2. - name: envoy.filters.http.header_to_metadata
  3. typed_config:
  4. "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
  5. request_rules:
  6. - cookie: cookie
  7. on_header_present:
  8. metadata_namespace: envoy.lb
  9. key: version
  10. type: STRING
  11. on_header_missing:
  12. metadata_namespace: envoy.lb
  13. key: default
  14. value: 'true'
  15. type: STRING
  16. remove: false

A corresponding upstream cluster configuration could be:

  1. clusters:
  2. - name: versioned-cluster
  3. type: EDS
  4. lb_policy: ROUND_ROBIN
  5. lb_subset_config:
  6. fallback_policy: ANY_ENDPOINT
  7. subset_selectors:
  8. - keys:
  9. - default
  10. - keys:
  11. - version

This would then allow requests with the x-version header set to be matched against endpoints with the corresponding version. Whereas requests with that header missing would be matched with the default endpoints.

If the header’s value needs to be transformed before it’s added to the request as dynamic metadata, this filter supports regex matching and substitution:

  1. http_filters:
  2. - name: envoy.filters.http.header_to_metadata
  3. typed_config:
  4. "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
  5. request_rules:
  6. - header: ":path"
  7. on_header_present:
  8. metadata_namespace: envoy.lb
  9. key: cluster
  10. regex_value_rewrite:
  11. pattern:
  12. google_re2: {}
  13. regex: "^/(cluster[\\d\\w-]+)/?.*$"
  14. substitution: "\\1"

Note that this filter also supports per route configuration:

  1. route_config:
  2. name: local_route
  3. virtual_hosts:
  4. - name: local_service
  5. domains: ["*"]
  6. routes:
  7. - match: { prefix: "/version-to-metadata" }
  8. route: { cluster: service }
  9. typed_per_filter_config:
  10. envoy.filters.http.header_to_metadata:
  11. "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
  12. request_rules:
  13. - header: x-version
  14. on_header_present:
  15. metadata_namespace: envoy.lb
  16. key: version
  17. type: STRING
  18. remove: false
  19. - match: { prefix: "/" }
  20. route: { cluster: some_service }

This can be used to either override the global configuration or if the global configuration is empty (no rules), it can be used to only enable the filter at a per route level.

Statistics

Currently, this filter generates no statistics.