Repository navigation
fix(git): limit size of request bodies buffered in memory - #422
Conversation
Upload-pack negotiation and ensure-refs bodies are read fully into memory, so an oversized or endless (chunked) body could exhaust cachewd's memory. These bodies are now capped by the new git max-request-body-mb option (default 100MB, matching GIT_HTTP_MAX_REQUEST_BUFFER), returning 413 when exceeded. Streamed requests such as cache PUTs (cache warming), pushes, and other proxied requests are unaffected. Amp-Thread-ID: https://ampcode.com/threads/T-01a1a052-93bd-73a1-83b2-d55b78c2b1c0 Co-authored-by: Amp <amp@ampcode.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fab778b801
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // limitRequestBody caps the body of requests whose body is buffered in memory, so a client can't exhaust memory with | ||
| // an oversized or endless body. Declared oversized bodies are rejected immediately; chunked bodies fail on read with an | ||
| // error matched by [requestTooLarge]. It returns false if it wrote a response. |
There was a problem hiding this comment.
The added three-line comment describes what this small, self-explanatory private helper does, but the repository explicitly permits comments only for non-obvious blocks of at least 20 lines and requires comments to explain why rather than what. Remove this comment and rely on the helper’s naming.
AGENTS.md reference: AGENTS.md:L19-L22
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Removed in 542f1a9, along with the inline comment in handleGitRequest.
Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-01a1a052-93bd-73a1-83b2-d55b78c2b1c0
542f1a9 to
5dd67e8
Compare
Upload-pack negotiation bodies and
ensure-refsJSON bodies are read fully into memory (to hash a spool key, to replay after a "not our ref" fallback, and to work aroundcgi.Handlerrejecting chunked bodies). A client could send an oversized or endless chunked body and exhaust cachewd's memory.This adds a git strategy option,
max-request-body-mb(default 100, matching theGIT_HTTP_MAX_REQUEST_BUFFER=100Mwe already pass togit http-backend;0disables it). It applies only where bodies are buffered:git-upload-packPOSTs, for both ready mirrors and mirrors that are still cloning (spooling)ensure-refsRequests whose
Content-Lengthexceeds the limit are rejected with 413 before any work is done. Chunked bodies are wrapped inhttp.MaxBytesReaderand also return 413 when they cross the limit. They are not forwarded upstream, because the body has already been partly consumed.Streamed requests are not limited: cache
PUTs (cache warming),git-receive-packpushes, LFS, and other requests proxied to upstream.Tests:
TestRequestBodyLimitcovers a 750KB body under a 1MB limit (served), oversized bodies with a declared length and with chunked encoding, the cloning/spool path, andensure-refs. Without the limit, all four oversized cases fail.