HTTP routing

• Virtual hosts that map domains/authorities to a set of routing rules.
• Prefix and exact path matching rules (both and case insensitive). Regex/slug matching is not currently supported, mainly because it makes it difficult/impossible to programmatically determine whether routing rules conflict with each other. For this reason we don’t recommend regex/slug routing at the reverse proxy level, however we may add support in the future depending on demand.
• TLS redirection at the virtual host level.
• /host redirection at the route level.
• .
• Automatic host rewriting based on the DNS name of the selected upstream host.
• .
• Websocket upgrades at route level.
• specified either via HTTP header or via route configuration.
• Request timeout specified either via HTTP header or via .
• Traffic shifting from one upstream cluster to another via runtime values (see ).
• Traffic splitting across multiple upstream clusters using weight/percentage-based routing (see ).
• Virtual cluster specifications. A virtual cluster is specified at the virtual host level and is used by Envoy to generate additional statistics on top of the standard cluster level ones. Virtual clusters can use regex matching.
• Priority based routing.
• based routing.
• Absolute urls are supported for non-tls forward proxies.

The for the HTTP connection manager owns the route table that is used by all configured HTTP filters. Although the router filter is the primary consumer of the route table, other filters also have access in case they want to make decisions based on the ultimate destination of the request. For example, the built in rate limit filter consults the route table to determine whether the global rate limit service should be called based on the route. The connection manager makes sure that all calls to acquire a route are stable for a particular request, even if the decision involves randomness (e.g. in the case of a runtime configuration route rule).

Envoy allows retries to be configured both in the as well as for specific requests via request headers. The following configurations are possible:

• Maximum number of retries: Envoy will continue to retry any number of times. An exponential backoff algorithm is used between each retry. Additionally, all retries are contained within the overall request timeout. This avoids long request times due to a large number of retries.
• Retry conditions: Envoy can retry on different types of conditions depending on application requirements. For example, network failure, all 5xx response codes, idempotent 4xx response codes, etc.

Note that retries may be disabled depending on the contents of the .

The currently supported priorities are default and high.

Envoy supports the sending of “direct” responses. These are preconfigured HTTP responses that do not require proxying to an upstream server.

There are two ways to specify a direct response in a Route:

• Set the direct_response field. This works for all HTTP response statuses.
• Set the field. This works for redirect response statuses only, but it simplifies the setting of the Location header.

Attention

If a response body is specified, it must be no more than 4KB in size, regardless of whether it is provided inline or in a file. Envoy currently holds the entirety of the body in memory, so the 4KB limit is intended to keep the proxy’s memory footprint from growing too large.

If response_headers_to_add has been set for the Route or the enclosing Virtual Host, Envoy will include the specified headers in the direct HTTP response.