Envoy’s default Header Validator config (proto)

extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig

[extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig proto]

This extension validates that HTTP request and response headers are well formed according to respective RFCs.

The validator performs comprehensive HTTP header validation including:

  1. HTTP/1 header map validity according to RFC 7230 section 3.2.

  2. Syntax of HTTP/1 request target URI and response status.

  3. HTTP/2 header map validity according to RFC 7540 section 8.1.2.

  4. Syntax of HTTP/2 pseudo headers.

  5. HTTP/3 header map validity according to RFC 9114 section 4.3.

  6. Syntax of HTTP/3 pseudo headers.

  7. Syntax of Content-Length and Transfer-Encoding.

  8. Validation of HTTP/1 requests with both Content-Length and Transfer-Encoding headers.

  9. Normalization of the URI path according to Normalization and Comparison without case normalization.

This validator ensures that HTTP traffic processed by Envoy conforms to established standards and helps prevent issues caused by malformed headers or invalid HTTP syntax.

{
  "http1_protocol_options": {...},
  "uri_path_normalization_options": {...},
  "restrict_http_methods": ...,
  "headers_with_underscores_action": ...,
  "strip_fragment_from_path": ...
}
http1_protocol_options

(extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.Http1ProtocolOptions) HTTP/1 protocol specific options. These settings control HTTP/1 specific validation behaviors.

uri_path_normalization_options

(extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions) The URI path normalization options.

By default Envoy normalizes URI path using the default values of the UriPathNormalizationOptions. URI path transformations specified by the uri_path_normalization_options configuration can be applied to a portion of requests by setting the envoy_default_header_validator.uri_path_transformations runtime value.

Attention

Disabling path normalization may lead to path confusion vulnerabilities in access control or incorrect service selection.

restrict_http_methods

(bool) Restrict HTTP methods to these defined in the RFC 7231 section 4.1.

Envoy will respond with 400 to requests with disallowed methods. By default methods with arbitrary names are accepted.

This setting helps enforce HTTP compliance and can prevent attacks that rely on non-standard HTTP methods.

headers_with_underscores_action

(extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.HeadersWithUnderscoresAction) Action to take when a client request with a header name containing underscore characters is received.

If this setting is not specified, the value defaults to ALLOW.

This setting provides security control over headers with underscores, which can be a source of security issues when different systems interpret underscores and hyphens differently.

strip_fragment_from_path

(bool) Allow requests with fragment in URL path and strip the fragment before request processing.

By default Envoy rejects requests with fragment in URL path. When this option is enabled, the fragment portion (everything after #) will be removed from the path before further processing.

Fragments are typically used by client-side applications and should not normally be sent to the server, so stripping them can help normalize requests.

extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions

[extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions proto]

Configuration options for URI path normalization and transformation.

These options control how Envoy processes and normalizes incoming request URI paths to ensure consistent behavior and security. Path normalization helps prevent path traversal attacks and ensures that equivalent paths are handled consistently.

{
  "skip_path_normalization": ...,
  "skip_merging_slashes": ...,
  "path_with_escaped_slashes_action": ...
}
skip_path_normalization

(bool) Should paths be normalized according to RFC 3986?

This operation overwrites the original request URI path and the new path is used for processing of the request by HTTP filters and proxied to the upstream service. Envoy will respond with 400 to requests with malformed paths that fail path normalization. The default behavior is to normalize the path.

This value may be overridden by the runtime variable http_connection_manager.normalize_path. See Normalization and Comparison for details of normalization.

Note

Envoy does not perform case normalization. URI path normalization can be applied to a portion of requests by setting the envoy_default_header_validator.path_normalization runtime value.

skip_merging_slashes

(bool) Determines if adjacent slashes in the path are merged into one.

This operation overwrites the original request URI path and the new path is used for processing of the request by HTTP filters and proxied to the upstream service. Setting this option to true will cause incoming requests with path //dir///file to not match against route with prefix match set to /dir. Defaults to false.

Note

Slash merging is not part of the HTTP spec and is provided for convenience. Merging of slashes in URI path can be applied to a portion of requests by setting the envoy_default_header_validator.merge_slashes runtime value.

path_with_escaped_slashes_action

(extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions.PathWithEscapedSlashesAction) The action to take when request URL path contains escaped slash sequences (%2F, %2f, %5C and %5c).

This operation may overwrite the original request URI path and the new path is used for processing of the request by HTTP filters and proxied to the upstream service.

The handling of escaped slashes is important for security as these sequences can be used in path confusion attacks to bypass access controls.

Enum extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions.PathWithEscapedSlashesAction

[extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions.PathWithEscapedSlashesAction proto]

Determines the action for requests that contain %2F, %2f, %5C or %5c sequences in the URI path. This operation occurs before URL normalization and the merge slashes transformations if they were enabled.

Escaped slash sequences in URLs can be used for path confusion attacks, so proper handling is important for security.

IMPLEMENTATION_SPECIFIC_DEFAULT

(DEFAULT) ⁣Default behavior specific to implementation (i.e. Envoy) of this configuration option. Envoy, by default, takes the KEEP_UNCHANGED action.

Note

The implementation may change the default behavior at-will.

KEEP_UNCHANGED

⁣Keep escaped slashes unchanged in the URI path. This preserves the original request path without any modifications to escaped sequences.

REJECT_REQUEST

⁣Reject client request with the 400 status. gRPC requests will be rejected with the INTERNAL (13) error code. The httpN.downstream_rq_failed_path_normalization counter is incremented for each rejected request.

This is the safest option when security is a primary concern, as it prevents any potential path confusion attacks by rejecting requests with escaped slashes entirely.

UNESCAPE_AND_REDIRECT

⁣Unescape %2F and %5C sequences and redirect the request to the new path if these sequences were present. The redirect occurs after path normalization and merge slashes transformations if they were configured.

Note

gRPC requests will be rejected with the INTERNAL (13) error code. This option minimizes possibility of path confusion exploits by forcing request with unescaped slashes to traverse all parties: downstream client, intermediate proxies, Envoy and upstream server.

The httpN.downstream_rq_redirected_with_normalized_path counter is incremented for each redirected request.

UNESCAPE_AND_FORWARD

⁣Unescape %2F and %5C sequences.

Attention

This option should not be enabled if intermediaries perform path based access control as it may lead to path confusion vulnerabilities.

extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.Http1ProtocolOptions

[extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.Http1ProtocolOptions proto]

HTTP/1 protocol specific options for header validation.

These options control how Envoy handles HTTP/1 specific behaviors and edge cases that may not apply to HTTP/2 or HTTP/3 protocols.

{
  "allow_chunked_length": ...
}
allow_chunked_length

(bool) Allows Envoy to process HTTP/1 requests/responses with both Content-Length and Transfer-Encoding headers set. By default such messages are rejected, but if option is enabled - Envoy will remove the Content-Length header and process the message.

See RFC7230, sec. 3.3.3 for details.

Attention

Enabling this option might lead to request smuggling vulnerabilities, especially if traffic is proxied via multiple layers of proxies.

Enum extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.HeadersWithUnderscoresAction

[extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.HeadersWithUnderscoresAction proto]

Action to take when Envoy receives client request with header names containing underscore characters.

Underscore character is allowed in header names by RFC-7230, and this behavior is implemented as a security measure due to systems that treat _ and - as interchangeable. Envoy by default allows client request headers with underscore characters.

This setting provides control over how to handle such headers for security and compatibility reasons.

ALLOW

(DEFAULT) ⁣Allow headers with underscores. This is the default behavior.

REJECT_REQUEST

⁣Reject client request. HTTP/1 requests are rejected with the 400 status. HTTP/2 requests end with the stream reset. The httpN.requests_rejected_with_underscores_in_headers counter is incremented for each rejected request.

DROP_HEADER

⁣Drop the client header with name containing underscores. The header is dropped before the filter chain is invoked and as such filters will not see dropped headers. The httpN.dropped_headers_with_underscores is incremented for each dropped header.