HTTP connection management

    HTTP connection manager configuration.

    Envoy’s HTTP connection manager has native support for HTTP/1.1, WebSockets, and HTTP/2. It does not support SPDY. Envoy’s HTTP support was designed to first and foremost be an HTTP/2 multiplexing proxy. Internally, HTTP/2 terminology is used to describe system components. For example, an HTTP request and response take place on a stream. A codec API is used to translate from different wire protocols into a protocol agnostic form for streams, requests, responses, etc. In the case of HTTP/1.1, the codec translates the serial/pipelining capabilities of the protocol into something that looks like HTTP/2 to higher layers. This means that the majority of the code does not need to understand whether a stream originated on an HTTP/1.1 or HTTP/2 connection.

    HTTP header sanitizing

    The HTTP connection manager performs various header sanitizing actions for security reasons.

    Each has an associated route table. The route table can be specified in one of two ways:

    • Statically.
    • Dynamically via the .

    Retry plugin configuration

    Normally during retries, host selection follows the same process as the original request. Retry plugins can be used to modify this behavior, and they fall into two categories:

    • : These predicates can be used to adjust the priority load used when selecting a priority for a retry attempt. Only one such predicate may be specified.

      • envoy.retry_priority.previous_priorities: This will keep track of previously attempted priorities, and adjust the priority load such that other priorities will be targeted in subsequent retry attempts.

    Host selection will continue until either the configured predicates accept the host or a configurable max attempts has been reached.

    These plugins can be combined to affect both host selection and priority load. Envoy can also be extended with custom retry plugins similar to how custom filters can be added.

    Configuration Example

    For example, to configure retries to prefer hosts that haven’t been attempted already, the built-in predicate can be used:

    This will reject hosts previously attempted, retrying host selection a maximum of 3 times. The bound on attempts is necessary in order to deal with scenarios in which finding an acceptable host is either impossible (no hosts satisfy the predicate) or very unlikely (the only suitable host has a very low relative weight).

    To configure retries to attempt other priorities during retries, the built-in can be used.

    This will target priorities in subsequent retry attempts that haven’t been already used. The parameter decides how often the priority load should be recalculated.

    These plugins can be combined, which will exclude both previously attempted hosts as well as previously attempted priorities.

    Internal redirects are configured via the ref:redirect action field in route configuration. When redirect handling is on, any 302 response from upstream is subject to the redirect being handled by Envoy.

    For a redirect to be handled successfully it must pass the following checks:

    1. Be a 302 response.
    2. Have a location header with a valid, fully qualified URL matching the scheme of the original request.
    3. The request must have been fully processed by Envoy.
    4. The request must not have a body.
    5. The request must have not been previously redirected, as determined by the presence of an x-envoy-original-url header.

    Any failure will result in redirect being passed downstream instead.

    Once the redirect has passed these checks, the request headers which were shipped to the original upstream will be modified by:

    1. Replacing the Authority/Host, Scheme, and Path headers with the values from the Location header.

    The altered request headers will then have a new route selected, be sent through a new filter chain, and then shipped upstream with all of the normal Envoy request sanitization taking place.

    Warning

    Note that HTTP connection manager sanitization such as clearing untrusted headers will only be applied once. Per-route header modifications will be applied on both the original route and the second route, even if they are the same, so be careful configuring header modification rules to avoid duplicating undesired header values.

    A sample redirect flow might look like this:

    1. Client sends a GET request for
    2. Upstream 1 sends a 302 with “location: http://baz.com/eep”
    3. Envoy is configured to allow redirects on the original route, and sends a new GET request to Upstream 2, to fetch with the additional request header “x-envoy-original-url: http://foo.com/bar”
    4. Envoy proxies the response data for to the client as the response to the original request.

    Timeouts

    • Connection-level : this applies to the idle period where no streams are active.
    • Connection-level drain timeout: this spans between an Envoy originated GOAWAY and connection termination.
    • Stream-level idle timeout: this applies to each individual stream. It may be configured at both the and per-route granularity. Header/data/trailer events on the stream reset the idle timeout.
    • Stream-level : this bounds the upstream timeout and allows the timeout to be overridden via the grpc-timeout request header.