Envoy’s default Header Validator config (proto)¶
This extension validates that HTTP request and response headers are well formed according to respective RFCs.
HTTP/1 header map validity according to RFC 7230 section 3.2
Syntax of HTTP/1 request target URI and response status
HTTP/2 header map validity according to RFC 7540 section 8.1.2
Syntax of HTTP/2 pseudo headers
HTTP/3 header map validity according to RFC 9114 section 4.3
Syntax of HTTP/3 pseudo headers
Syntax of Content-Length and Transfer-Encoding
Validation of HTTP/1 requests with both
(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_optionsconfiguration can be applied to a portion of requests by setting the
envoy_default_header_validator.uri_path_transformationsruntime value. Caution: disabling path normalization may lead to path confusion vulnerabilities in access control or incorrect service selection.
(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.
(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 that Envoy does not perform case normalization URI path normalization can be applied to a portion of requests by setting the
(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///fileto not match against route with
prefixmatch set to
/dir. Defaults to
false. Note that slash merging is not part of HTTP spec and is provided for convenience. Merging of slashes in URI path can be applied to a portion of requests by setting the
(extensions.http.header_validators.envoy_default.v3.HeaderValidatorConfig.UriPathNormalizationOptions.PathWithEscapedSlashesAction) The action to take when request URL path contains escaped slash sequences (
%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.
Determines the action for requests that contain
%5c sequences in the URI path.
This operation occurs before URL normalization and the merge slashes transformations if they were enabled.
(DEFAULT) Default behavior specific to implementation (i.e. Envoy) of this configuration option. Envoy, by default, takes the
KEEP_UNCHANGEDaction. NOTE: the implementation may change the default behavior at-will.
Keep escaped slashes.
Reject client request with the 400 status. gRPC requests will be rejected with the
INTERNAL(13) error code. The
http#.downstream_rq_failed_path_normalizationcounter is incremented for each rejected request.
%5Csequences 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
http#.downstream_rq_redirected_with_normalized_pathcounter is incremented for each redirected request.
%5Csequences. Note: this option should not be enabled if intermediaries perform path based access control as it may lead to path confusion vulnerabilities.
(bool) Allows Envoy to process HTTP/1 requests/responses with both
Transfer-Encodingheaders set. By default such messages are rejected, but if option is enabled - Envoy will remove the
Content-Lengthheader and process the message. See RFC7230, sec. 3.3.3 for details.
Enabling this option might lead to request smuggling vulnerabilities, especially if traffic is proxied via multiple layers of proxies.
Action to take when Envoy receives client request with header names containing underscore characters. Underscore character is allowed in header names by the 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.
(DEFAULT) Allow headers with underscores. This is the default behavior.
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 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.