HTTP Filters, Routing, gRPC, and WebSocket Support in Envoy

HTTP Filters

Envoy supports an HTTP‑level filter stack within its connection manager, allowing developers to write filters that operate on request and response streams without needing to know the underlying transport protocol (HTTP/1.1, HTTP/2, etc.). Three filter types exist: decoder filters (called while decoding request headers, body, and trailers), encoder filters (called while encoding response headers, body, and trailers), and combined decoder/encoder filters (called at both stages).

The filter API enables operations such as health‑check handling, rate‑limit service calls, buffering, routing, and generating statistics for application traffic (e.g., DynamoDB). Envoy ships with several built‑in HTTP filters, and their configuration is documented elsewhere.

HTTP Routing

Envoy includes an HTTP router filter for advanced routing tasks, useful for edge traffic handling and for services inside an Envoy mesh. The router matches incoming requests to upstream clusters, obtains a connection pool, and forwards the request. Supported features include virtual hosts, prefix and exact path matching, TLS redirects at the virtual‑host level, path/host redirects, explicit and automatic host rewrites, prefix rewrites, WebSocket upgrades, request retries and timeouts, traffic shifting based on runtime values or weighted percentages, arbitrary header matching, virtual cluster specifications, priority‑based routing, hash‑based routing, and absolute‑URL support for non‑forward proxies.

Route Table

The HTTP connection manager holds a route table used by the router filter and other filters (e.g., rate‑limit filter) to make routing decisions. The manager guarantees stable routing lookups for a given request, even when routing rules involve randomness.

Retry Semantics

Envoy allows configuring maximum retry attempts with exponential back‑off, and retry conditions such as network failures, 5xx responses, or idempotent 4xx responses. Retries are subject to the overall request timeout and can be disabled via the x‑envoy‑retry‑grpc‑status header.

Priority Routing

Envoy supports priority routing, using separate connection pools and circuit‑breaker settings per priority level. Currently, default and high priorities are available, with future plans for true HTTP/2 priority support.

gRPC Support

Envoy provides first‑class gRPC support on both transport and application layers, leveraging HTTP/2 trailers for request status. It includes a gRPC‑bridge filter to translate gRPC over HTTP/1.1 to HTTP/2, a gRPC‑Web filter for browser‑based clients, and a gRPC‑JSON transcoder to expose RESTful JSON APIs for gRPC services.

WebSocket Support

Envoy can upgrade HTTP/1.1 connections to WebSocket when the route is explicitly configured with use_websocket and the client sends the correct upgrade headers. WebSocket traffic is treated as pure TCP, so all WebSocket drafts are supported, though certain HTTP‑level features (redirects, timeouts, retries, rate limiting) are not applicable. Prefix rewrites, host rewrites, and traffic shifting remain functional.

Connection Semantics

WebSocket upgrades are proxied like ordinary TCP streams; Envoy does not interpret WebSocket frames. The downstream client and upstream server are responsible for proper termination of the WebSocket and underlying TCP connections.

Cluster Manager

The cluster manager maintains all configured upstream clusters, exposing APIs to filters for obtaining L3/L4 connections or abstracted HTTP connection pools, regardless of the underlying protocol (HTTP/1.1, HTTP/2, TCP, UDS). Clusters can be statically defined or dynamically discovered via the CDS API, reducing the need for Envoy restarts when topology changes.

Key cluster‑manager configuration items include static cluster definitions and CDS settings.