feat(supervisor): stream HTTP session hook uploads on the plain-HTTP forward proxy
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 32/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- backend, networking
Direzione di ricerca
Start by reading ForwardMiddlewarePipeline::apply in crates/openshell-supervisor-network/src/proxy.rs and compare it with how request_body_delivery(config) in l7/relay.rs picks a delivery per route. Read docs/extensibility/supervisor-middleware/operations.mdx for the current 4 MiB wording. Write the forward-proxy denial test first (body_over_limit, upstream sees nothing), then stream middleware output for routes that need no body-wide work. Done means the new tests pass and the limits text matches actual behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
User Story
As an operator running an HTTP session hook that streams request bodies (for example a signing or redaction stage), I want plain-HTTP requests sent through the forward proxy to behave like requests on the L7 relay, so that uploads larger than 4 MiB are not denied depending on how the sandbox reached the endpoint.
Problem Statement
HTTP session hooks have no total size cap on STREAM request bodies on the L7 relay paths. The plain-HTTP forward proxy (ForwardMiddlewarePipeline::apply in crates/openshell-supervisor-network/src/proxy.rs) always passes RequestBodyDelivery::WITHHOLD, because it writes the request upstream as one buffer. The preflight therefore advertises limits.max_output_body_bytes of 4 MiB (MAX_MIDDLEWARE_PAYLOAD_BYTES), and a larger upload that matches a session request hook fails with failure_code: body_over_limit.
The limit is documented in Supported Operations (forward-proxy requests buffer output, 4 MiB), but the same hook behaves differently depending on the path a request takes. There is also no test covering the forward-proxy denial.
Raised in review of #4359: https://github.com/NVIDIA/OpenShell/pull/4359#discussion_r4381863330
Impact / Why This Matters
- Inconsistent behavior for one middleware config: an upload over 4 MiB succeeds via the L7 relay and fails via the forward proxy.
- It undercuts the "no total size cap" goal of HTTP session hooks for clients that use
HTTP_PROXYwith plain HTTP.
Proposed Design
- Add a test now: a forward-proxy upload over 4 MiB that matches a session request hook is denied with
failure_code: body_over_limit, and the upstream sees nothing. - Stream middleware output on the forward proxy, like the REST relay, when the route needs no body-wide work (no SigV4 signing, body credential rewrite, or body-aware L7 re-evaluation such as JSON-RPC/MCP/GraphQL). Keep
WITHHOLDwith its route limit for those cases. - Update the Supported Operations limits text once forward-proxy streaming lands.
Acceptance Criteria
- A test covers the 4 MiB forward-proxy denial (
body_over_limit, nothing forwarded). - A plain-HTTP forward-proxy upload over 4 MiB through a STREAM session request stage succeeds on routes that need no body-wide work, with
max_output_body_bytesunset in the preflight. - Routes that still need the whole body keep their documented limits.
- Docs describe the forward-proxy behavior.
Alternatives Considered
- Keep buffering and only document the limit. That leaves the path-dependent behavior in place.
Agent Investigation
proxy.rsForwardMiddlewarePipeline::applycallsapply_request_with_delivery(..., RequestBodyDelivery::WITHHOLD)with the comment "The forward proxy writes the request as one buffer, so middleware output is withheld and inlined."- The L7 REST relay chooses delivery per route via
request_body_delivery(config)inl7/relay.rs. - Docs:
docs/extensibility/supervisor-middleware/operations.mdx(request output buffering paragraph) already lists the forward proxy among buffered paths.
- Lingua principale
- Rust
- Stelle
- 20.6k
- Fork
- 2k
- Merge medio
- 2g 14h
- PR unite (30g)
- 275
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NVIDIA/OpenShell
-
config preflight exits 0 on allow_unauthenticated_users = trueForse già presa @ericcurtin l’ha presa 1 giorno fa. Apertastate:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
state:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
bug(python): OIDC refresh drops the gateway's oidc_scopesForse di nuovo libera @jyotir07 l’ha presa 8 giorni fa e non c’è nessuna pull request aperta. Apertastate:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
NVIDIA/OpenShell#4919 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug: workspace access hint suggests a --subject command that fails for hyphen-leading OIDC subjectsForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di NVIDIA/OpenShell
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
riverqueue/river#1576 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
stadelmanma/fitparse-rs#64 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno