Envoy includes an HTTP router filter which can be installed to
perform advanced routing tasks. This is useful both for handling edge traffic (traditional reverse
proxy request handling) as well as for building a service to service Envoy mesh (typically via
routing on the host/authority HTTP header to reach a particular upstream service cluster). Envoy
also has the ability to be configured as forward proxy. In the forward proxy configuration, mesh
clients can participate by appropriately configuring their http proxy to be an Envoy. At a high
level the router takes an incoming HTTP request, matches it to an upstream cluster, acquires a
connection pool to a host in the upstream cluster, and forwards the
request. The router filter supports the following features:

Virtual hosts that map domains/authorities to a set of routing rules.

Prefix and exact path matching rules (both case sensitive 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.

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.

The configuration 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).

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.

Host selection retry plugins: Envoy can be configured to apply additional logic to the host
selection logic when selecting hosts for retries. Specifying a
retry host predicate
allows for reattempting host selection when certain hosts are selected (e.g. when an already
attempted host is selected), while a
retry priority can be
configured to adjust the priority load used when selecting a priority for retries.

Envoy supports priority routing at the route level.
The current priority implementation uses different connection pool
and circuit breaking settings for each
priority level. This means that even for HTTP/2 requests, two physical connections will be used to
an upstream host. In the future Envoy will likely support true HTTP/2 priority over a single
connection.

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

A direct response has an HTTP status code and an optional body. The Route configuration
can specify the response body inline or specify the pathname of a file containing the
body. If the Route configuration specifies a file pathname, Envoy will read the file
upon configuration load and cache the contents.

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.