Epic: External Processing

[shaneutt]

External processing filter for request/response mutation via gRPC callout, compatible with the Envoy ext_proc protocol. Praxis acts as an ext_proc client, calling out to external processing services during request/response handling.

Relationship to extproc/

The extproc/ directory in the monorepo is the server side: Praxis acting as an ext_proc server for Envoy. This epic covers the client side: Praxis calling out to external processors from within its own filter pipeline.

ext_proc Protocol Phases

Six processing phases, each independently configurable:

• request_headers: before forwarding request headers upstream
• request_body: before forwarding request body upstream
• response_headers: before forwarding response headers downstream
• response_body: before forwarding response body downstream
• request_trailers: before forwarding request trailers upstream
• response_trailers: before forwarding response trailers downstream

Processing Modes

Per-phase processing mode configuration:

• skip: do not send this phase to the external processor
• send: stream data to processor as it arrives
• buffered: buffer entire content before sending to processor
• buffered_partial: buffer up to a configured limit, then send

Default: send headers, skip body.

Mutation Types

Mutations returned by the external processor:

• HeaderMutation: add, remove, or overwrite request/response headers
• BodyMutation: replace request/response body content
• ImmediateResponse: short-circuit the pipeline, return a response directly to the client

Filter Integration

• ext_proc implemented as an HttpFilter under filter/src/builtins/http/payload_processing/
• Delegates to external gRPC service at each configured phase
• Applies returned mutations to the request/response flowing through the pipeline

Connection Management

• gRPC connection pooling to external processor endpoints
• Configurable keepalive interval and timeout
• Reconnection with backoff on connection failure
• Timeout cascading: connection timeout < request timeout < filter timeout

Failure Handling

• Configurable fail-open (continue with unmodified request) vs fail-closed (reject request)
• Default: fail-closed (safe default)
• Timeout treated as failure, policy applies
• Per-filter failure mode configuration

Related Issues

• Epic: Extensibility Platform #164 Extensibility Platform (v0.5.0) - parent category
• Dynamic Filter Loading via Shared Libraries #133 Dynamic Filter Loading via Shared Libraries (v0.5.0) - related extensibility