When rproxy answers a request before reading its whole body (a 413 for a body announced over SWW_RPROXY_MAX_REQUEST_SIZE, or a deny), and the visitor's request carries Connection: close, Go's server closes the connection without reading the rest of the body. The visitor, still sending, gets a reset and may never read the answer.
The comment on answer in internal/rproxy/request.go says a visitor may go on sending so that Go's server can read the rest and end the request cleanly. Go's server skips that read when the request says Connection: close.
Example: a client posts 129 KiB with Connection: close and a 128 KiB limit. rproxy sends the 413 and closes; the client's next write fails with broken pipe or connection reset by peer.
Found while fixing the test in #371, which now avoids this case.
Done when such a visitor reads rproxy's answer, the rest of its body read until the request time limit, as for a visitor without Connection: close.
Model: opus-5-5
When rproxy answers a request before reading its whole body (a 413 for a body announced over `SWW_RPROXY_MAX_REQUEST_SIZE`, or a deny), and the visitor's request carries `Connection: close`, Go's server closes the connection without reading the rest of the body. The visitor, still sending, gets a reset and may never read the answer.
- The comment on `answer` in `internal/rproxy/request.go` says a visitor may go on sending so that Go's server can read the rest and end the request cleanly. Go's server skips that read when the request says `Connection: close`.
- Example: a client posts 129 KiB with `Connection: close` and a 128 KiB limit. rproxy sends the 413 and closes; the client's next write fails with `broken pipe` or `connection reset by peer`.
- Found while fixing the test in https://git.eeqj.de/sneak/smallwebwaf/issues/371, which now avoids this case.
Done when such a visitor reads rproxy's answer, the rest of its body read until the request time limit, as for a visitor without `Connection: close`.
Model: opus-5-5
rproxy now reads the rest of the body itself, once it has answered, for a visitor that sent Connection: close. The read stops at the request time limit or after 256 KiB, as Go's server does for other visitors.
Model: opus-5-5
PR: https://git.eeqj.de/sneak/smallwebwaf/pulls/375 (branch `issue-373-read-rest-after-connection-close`).
rproxy now reads the rest of the body itself, once it has answered, for a visitor that sent `Connection: close`. The read stops at the request time limit or after 256 KiB, as Go's server does for other visitors.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When rproxy answers a request before reading its whole body (a 413 for a body announced over
SWW_RPROXY_MAX_REQUEST_SIZE, or a deny), and the visitor's request carriesConnection: close, Go's server closes the connection without reading the rest of the body. The visitor, still sending, gets a reset and may never read the answer.answerininternal/rproxy/request.gosays a visitor may go on sending so that Go's server can read the rest and end the request cleanly. Go's server skips that read when the request saysConnection: close.Connection: closeand a 128 KiB limit. rproxy sends the 413 and closes; the client's next write fails withbroken pipeorconnection reset by peer.Done when such a visitor reads rproxy's answer, the rest of its body read until the request time limit, as for a visitor without
Connection: close.Model: opus-5-5
PR: #375 (branch
issue-373-read-rest-after-connection-close).rproxy now reads the rest of the body itself, once it has answered, for a visitor that sent
Connection: close. The read stops at the request time limit or after 256 KiB, as Go's server does for other visitors.Model: opus-5-5