Skip to content

fix(http tools): stop reading an upstream body at the tool's byte cap - #95

Merged
alexeybe1kin merged 1 commit into
mainfrom
fix/http-response-cap
Nov 13, 2026
Merged

alexeybe1kin merged 1 commit into
mainfrom
fix/http-response-cap

Conversation

@alexeybe1kin

Copy link
Copy Markdown
Collaborator

Hunt finding toolgate-1 F3 (re-verified on main, dispatch.py:113): client.request(...) read the whole body and only then compared len(response.content) with max_response_bytes (at most 1 MiB). A hostile or broken upstream could make ToolGate hold any amount in memory first.

The body is now read with client.stream and iter_bytes, and reading stops as soon as it passes the cap: RESPONSE_TOO_LARGE, which stays OUTCOME_UNKNOWN because the request was sent. Parsing uses json.loads on the bytes; ValueError still covers bad JSON and bad encoding.

Tests: toolgate/tests/test_http_response_cap.py. A 25 MiB body is cut off after at most 6 x 64 KiB chunks; this fails on main, which pulls all 400 chunks. A small chunked body is parsed. Two existing fakes (test_tool_secret_refs.py, test_tool_settings.py) moved from request to stream. Every test file using HTTP tools or public_client: 278 passed. Ruff and the type baseline are ok.

The response was fetched whole and only then compared with max_response_bytes, so a hostile or
broken upstream's huge body sat in ToolGate's memory first (toolgate-1 F3). The body is now
streamed and the read stops as soon as it passes the cap. Two tests faked client.request and
now fake client.stream.
@alexeybe1kin
alexeybe1kin merged commit 349abec into main Nov 13, 2026
4 checks passed
@alexeybe1kin
alexeybe1kin deleted the fix/http-response-cap branch November 13, 2026 09:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant