rproxy: cut off an answer that stalls after arriving before the whole request (closes #345)

Conversation 4 Commits 2 Files Changed 2

+105 -40

2 Commits

Author	SHA1	Message	Date
sneak	6a59011dee	rproxy: cut off an answer that stalls after arriving before the whole request (closes #345 ) check / check (push) Waiting to run Details When the app's answer arrived before the app had been sent the whole request, SWRP_MAX_RESPONSE_TIME_MS had no timer: only the end of the request started one. If the app then stalled, only a write could fail at the deadline. With nothing written, the connection stayed open until the request time limit. modifyResponse now starts the response timer when it ends the request. Once the timer cuts off the app's answer, nothing is left to flush, so the last flush in finish succeeded and Go's server read the rest of the body. finish now also ends that reading at once after a refusal of an answer already passed on. Model: opus-5-5	2026-11-11 08:45:51 +00:00
sneak	e3c5b4ecf8	rproxy tests: a cut-off answer closes the connection, also after its first part reached the visitor check / check (push) Waiting to run Details The app now sends its late parts only once rproxy has ended the request to it, not after a sleep timed against the limit. With the body in one part it stalls after its headers; with two parts, after the first part, which reaches the visitor. Both cases fail on the current code: nothing cuts the answer off, and the connection stays open. The 2-second limit lets rproxy pass on a part sent at once, even on a busy host. A new test, which passes on the current code, has every flush fail with no refusal, so that only the failed-flush check in finish ends the reading of the visitor's body. Model: opus-5-5	2026-11-11 08:45:51 +00:00

Author

SHA1

Message

Date

sneak

6a59011dee

rproxy: cut off an answer that stalls after arriving before the whole request (closes #345 )

check / check (push) Waiting to run

Details

When the app's answer arrived before the app had been sent the whole
request, SWRP_MAX_RESPONSE_TIME_MS had no timer: only the end of the
request started one. If the app then stalled, only a write could fail at
the deadline. With nothing written, the connection stayed open until the
request time limit.

modifyResponse now starts the response timer when it ends the request.
Once the timer cuts off the app's answer, nothing is left to flush, so the
last flush in finish succeeded and Go's server read the rest of the body.
finish now also ends that reading at once after a refusal of an answer
already passed on.

Model: opus-5-5

2026-11-11 08:45:51 +00:00

sneak

e3c5b4ecf8

rproxy tests: a cut-off answer closes the connection, also after its first part reached the visitor

check / check (push) Waiting to run

Details

The app now sends its late parts only once rproxy has ended the request to
it, not after a sleep timed against the limit. With the body in one part it
stalls after its headers; with two parts, after the first part, which
reaches the visitor. Both cases fail on the current code: nothing cuts the
answer off, and the connection stays open. The 2-second limit lets rproxy
pass on a part sent at once, even on a busy host.

A new test, which passes on the current code, has every flush fail with no
refusal, so that only the failed-flush check in finish ends the reading of
the visitor's body.

Model: opus-5-5

2026-11-11 08:45:51 +00:00

rproxy: cut off an answer that stalls after arriving before the whole request (closes #345) #348