Proposal/http callout filter#644
Conversation
Add the design and implementation plan for the http_callout filter: - Per-instance reqwest::Client with rustls-tls, connection and TLS isolation for multi-tenant safety (no shared pools across filter instances) - RFC 9535 JSONPath extraction via serde_json_path with config-time validation - Satellite crate at filter/http-callout/ behind an opt-in cargo feature flag, following the ext-proc pattern - Circuit breaker reuse from existing state machine - SSRF prevention via static config-declared targets - Fail-open/closed semantics, phase selection, body forwarding - 4-PR implementation sequence - Documents relationship to praxis-proxy#138 (ai_guardrails) with two integration paths Assisted by Opus 4.6
These are out of scope for prior art. Signed-off-by: Morgan Foster <39788015+usize@users.noreply.github.com>
Added details about the HTTP call-out filter implementation and requirements. Signed-off-by: Morgan Foster <39788015+usize@users.noreply.github.com>
Updated the HTTP callout filter documentation by removing outdated sections and renumbering subsequent items. Signed-off-by: Morgan Foster <39788015+usize@users.noreply.github.com>
|
Missing Signed-off-by: c8c991f. All commits require sign-off (via |
praxis-bot
left a comment
praxis-bot
left a comment
There was a problem hiding this comment.
PR Review
Summary: Adds the How? section to the HTTP callout filter proposal with requirements, crate layout, filter struct, request flow, configuration schema, implementation plan, and ext_authz lessons-learned addendum.
Overall: Well-structured proposal that aligns with existing proposal conventions and makes technically accurate claims about the codebase. The design is thorough and the implementation plan is reasonable. A few items need attention.
| Severity | Count |
|---|---|
| Medium | 3 |
Non-inline findings
None. All findings are inline.
| @@ -197,9 +197,341 @@ filter_chains: | |||
| in `praxis-proto`. | |||
| - **NGINX auth_request** — sub-request to an authorization | |||
| endpoint; response status controls access. | |||
There was a problem hiding this comment.
[Medium] The Lakera Guard and NVIDIA NeMo Guardrails entries were removed from Prior Art, but Lakera Guard is still the primary example throughout the proposal (motivation, example config, integration test plan). Either restore these entries or add a brief note explaining why they were removed. Removing prior art while retaining them as the central example is inconsistent.
| │ | ||
| ├─ depth check ──► >= max_depth? ──► apply failure_mode | ||
| │ | ||
| ├─ circuit breaker check ──► Open? ──► apply failure_mode |
There was a problem hiding this comment.
[Medium] The request flow diagram only shows the on_request_body(end_of_stream=true) entry point, but lines 355-360 describe an alternative phase: request_headers mode that runs in on_request with an empty body. Add a second entry branch to the flow diagram (or a note at the top) showing the on_request path, so the diagram covers both execution modes.
| #### SSRF prevention | ||
|
|
||
| Validation in `from_config()`: | ||
|
|
There was a problem hiding this comment.
[Medium] body_from: request_body appears to be the only possible value for this field (the design section does not mention any alternatives). If there is only one option, this config field is redundant with phase: request_body and should be removed to avoid implying other sources exist. If other values are planned (e.g. body_from: none, body_from: custom_json), list them or add a comment indicating this is extensible.
2 participants
Adds a how section to the http call out filter proposal.
This proposal splits the work into two deliverables:
#138 is called out as a target consumer of the new http call out library.