feat(supervisor): stream HTTP session hook uploads on the plain-HTTP forward proxy
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 32/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- rust
- 領域
- backend, networking
研究方向
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.
由索引模型根據 Issue 內容生成。
描述
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.
- 主要語言
- Rust
- 星號
- 21.1k
- 分支
- 2.1k
- 平均合併
- 2 天 10 小時
- 30 天內合併 PR
- 282
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
NVIDIA/OpenShell 的其他 Issue
-
state:triage-needed
難度 2/5 1-3 小時 新手友好度 73/100
維護者通常 1 天內回覆
-
config preflight exits 0 on allow_unauthenticated_users = true可能已有人在做 @ericcurtin 於 4 天前認領。 未關閉state:triage-needed
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 1 天內回覆
-
state:triage-needed
難度 2/5 1-3 小時 新手友好度 62/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆
-
bug(python): OIDC refresh drops the gateway's oidc_scopes可能重新可做 @jyotir07 於 11 天前認領,目前沒有進行中的 PR。 未關閉state:triage-needed
難度 2/5 1-3 小時 新手友好度 84/100
NVIDIA/OpenShell#4919 · 3 則留言 ·
維護者通常 1 天內回覆
相似的 Issue
-
enhancement
難度 2/5 1-3 小時 新手友好度 70/100
-
bug order-flow studies ui
難度 2/5 1-3 小時 新手友好度 88/100
userFRM/egui-charts#2417 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 2 天內回覆
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay live可能已有人在做 @ragelfundionctrumnar 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 68/100
UCS-Care-Group/mailcraft#862 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
smoltcp-rs/smoltcp#1243 ·
維護者通常 1 天內回覆