Refuse an oversized body before inviting it #413
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dejima/dejima#413
Reference in New Issue
Block a user
Summary generated by LLM agent
Fixes #400, which is what failed the
confined (proxy)job on #412 - a pull request that touchesbin/dejima-attachand nothing else.BaseHTTPRequestHandleranswers100 Continueand returns True beforedo_*runs, so the proxy invited the upload, read the declared length in_read_body, refused it with a413and closed mid-flight. Whether the client read the refusal or only the invitation was timing. Under load it loses: curl reports100where the test wants413, which is exactly what CI showed.The cap was doing the thing that matters - nothing oversized was read into host memory, and this runs on the host as the operator's own user. What was wrong was the conversation.
handle_expect_100now runs the same length check first, sends the413and returns False when it is over the cap. The client is never asked for a body it cannot send, and the answer is the same every time.Two things that are deliberately unchanged. A chunked request declares nothing, so it is still capped as it is read - there is no earlier moment to refuse it at. And a
Content-Lengththat is not a number still raises rather than being refused tidily, because the test for narrow error suppression uses that exact fault to prove the suppression is specific.The test
The existing test asks what the client ends up with, and it passes either way when the timing is kind - that is why this was a flake rather than a failure. The new one asks what the FIRST answer is, over a raw socket, and sends no body at all: the question the race cannot reach. With the override removed it reads
HTTP/1.1 100 Continue, which is the bug stated as a string.It is also cheaper than the one beside it, which writes 32MiB to disk to make its point.
Verified
Every confined suite and shellcheck, clean: eleven suites, no failures and no skips,
proxyat 59.On #412: nothing about that branch caused this, and nothing in it needs changing. Once this lands on
development, a branch that has it will stop seeing the flake; before then, re-running the job is the whole remedy, since the race is one a fast machine usually wins.