fix: close the socket after refusing an oversized declared body - #19
Merged
Conversation
The streaming reader destroys the request as soon as the body passes the cap, because otherwise a client keeps sending bytes and holds the sidecar open. The declared `Content-Length` rejection ran earlier and had no such guard: it threw before reading or destroying anything, so the request was never completed and the connection stayed open for the bytes the sidecar had already refused. A client can declare `Content-Length: 500000000` and trickle one byte every few seconds, resetting `requestTimeout` indefinitely and pinning a socket per connection. Verified against the reference server: an over-cap request with a partial body held the connection open past a 2s bound, while the same request on the streaming path was reset immediately. Reject after the response is delivered rather than before it, so the documented 413 contract is unchanged: the request is marked, the error is sent, and the socket is destroyed once the response finishes.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Comment on lines
31
to
32
| const contentEncoding = request.headers["content-encoding"]; | ||
| if (contentEncoding && contentEncoding.toLowerCase() !== "identity") { |
There was a problem hiding this comment.
🟨 Early rejections retain oversized uploads
An oversized upload remains open when routing or encoding validation rejects it before readJson. A trickling client can retain sockets after receiving an error.
Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
+435
to
+437
| response.once("finish", () => { | ||
| request.socket?.end(); | ||
| }); |
There was a problem hiding this comment.
🟥 Oversized uploads still retain sockets
A half-open client can keep trickling an oversized body after socket.end() sends the 413 and FIN. The server retains each connection because its readable half remains open, preserving the resource-exhaustion vector.
Was this helpful? React with 👍 or 👎 to provide feedback.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
readJsonrejects a declaredContent-LengthaboveMAX_BODY_BYTESbefore reading or destroying anything. The streaming path below it already destroys the request, with a comment explaining why:The early exit had no equivalent guard. A loopback client can declare
Content-Length: 500000000, send a small prefix, and then trickle one byte every few seconds. Each byte resets Node's inactivityrequestTimeout, so the request never completes and the socket stays open indefinitely, at almost no bandwidth cost.MAX_CONCURRENT_REQUESTSandmaxRequestsPerSocketdo not bound this because the handler has already returned.Verification
Added
HTTP sidecar closes an over-cap request instead of waiting for the declared body, which opens a raw socket, sends a POST declaring 5 MB with a partial body and no FIN, and waits up to 2s for the server to close.closed: falseafter 2004ms (connection held open). The test fails.Change
Marking the request on the over-cap path and destroying it once the error response finishes, rather than destroying before the response. This was necessary: destroying first, mirroring the streaming path exactly, broke the existing
HTTP sidecar rejects unsafe requests before state mutationtest, which asserts the client receives a413. The response contract is preserved; only the post-response socket state changes.Checks
npm run check: 139/139 (baseline 137, plus the new regression test and a companion test that a valid proposal on the same route still returns 201).Content-Length, or media-type rejections: those still respond normally and are covered by the existing suite.