cardinal-proxy 0.2.31

Pingora-based HTTP proxy implementation for the Cardinal gateway
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# cardinal-proxy

Pingora integration for Cardinal.  `CardinalProxy` implements `ProxyHttp` and delegates request/response processing to the rest of the stack.

## Key pieces

- `CardinalContextProvider`: resolves an `Arc<CardinalContext>` from a `Session`.  The default `StaticContextProvider` always returns the same context; more advanced deployments can plug in host-aware providers.
- `RequestContext`: per-request cache of the resolved context, destination backend, and `PluginRunner`.
- Middleware execution: `PluginRunner::run_request_filters` / `run_response_filters` are invoked at the right phases, so both Rust and WASM middleware can observe or mutate traffic.

## Lifecycle

1. Provider resolves a context.
2. `DestinationContainer` selects the backend based on path/host.
3. Request middleware runs; it can short-circuit with `MiddlewareResult::Responded`.
4. Pingora connects to the upstream origin.
5. Response middleware runs; optional logging is performed.

Consumers rarely touch this crate directly—`Cardinal` handles wiring—but understanding it is useful when implementing custom providers or debugging proxy behaviour.