When the app answers 101 Switching Protocols with an Upgrade other than the one the client sent (the client asks for websocket, foo, the app switches to websocket), ReverseProxy refuses to pass the switch on and calls answerError. modifyResponse had already counted the 101 as the client's status, so answer took the response as started and sent nothing, and Go's server sent an empty 200.
Now the 101 is noted only when ReverseProxy takes over the client's connection to send it: responseWriter gains a Hijack method that records it. Until then smallwebwaf can still answer, so a refused switch gets 502, logged with status 502 and action upstream_error. A switch that is passed on is logged with 101 as before.
answerError also closes the app's switched connection: when ReverseProxy refuses the switch, the transport has already handed that connection over, and nothing closes it until Go's garbage collector reclaims it.
Unverified: the test covers the 502 and the log line, not the close of the app's connection; in the test process the garbage collector closes that connection soon after even without the change, so a test cannot tell the two apart.
Judgement call: websocket stays true on the log line of a refused switch, since README says it records that the app switched protocols, which it did.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/smallwebwaf/issues/131.
When the app answers `101 Switching Protocols` with an `Upgrade` other than the one the client sent (the client asks for `websocket, foo`, the app switches to `websocket`), ReverseProxy refuses to pass the switch on and calls `answerError`. `modifyResponse` had already counted the `101` as the client's status, so `answer` took the response as started and sent nothing, and Go's server sent an empty `200`.
Now the `101` is noted only when ReverseProxy takes over the client's connection to send it: `responseWriter` gains a `Hijack` method that records it. Until then `smallwebwaf` can still answer, so a refused switch gets `502`, logged with status `502` and action `upstream_error`. A switch that is passed on is logged with `101` as before.
`answerError` also closes the app's switched connection: when ReverseProxy refuses the switch, the transport has already handed that connection over, and nothing closes it until Go's garbage collector reclaims it.
- Unverified: the test covers the `502` and the log line, not the close of the app's connection; in the test process the garbage collector closes that connection soon after even without the change, so a test cannot tell the two apart.
- Judgement call: `websocket` stays true on the log line of a refused switch, since README says it records that the app switched protocols, which it did.
Model: opus-5-5
ReverseProxy refuses a 101 whose Upgrade is not the one the client asked
for, but modifyResponse had already counted the 101 as sent, so
answerError sent nothing and the client got an empty 200. The 101 now
counts as sent only once ReverseProxy has taken over the client's
connection, and answerError closes the app's switched connection, which
ReverseProxy leaves open when it refuses the switch.
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.
Fixes #131.
When the app answers
101 Switching Protocolswith anUpgradeother than the one the client sent (the client asks forwebsocket, foo, the app switches towebsocket), ReverseProxy refuses to pass the switch on and callsanswerError.modifyResponsehad already counted the101as the client's status, soanswertook the response as started and sent nothing, and Go's server sent an empty200.Now the
101is noted only when ReverseProxy takes over the client's connection to send it:responseWritergains aHijackmethod that records it. Until thensmallwebwafcan still answer, so a refused switch gets502, logged with status502and actionupstream_error. A switch that is passed on is logged with101as before.answerErroralso closes the app's switched connection: when ReverseProxy refuses the switch, the transport has already handed that connection over, and nothing closes it until Go's garbage collector reclaims it.502and the log line, not the close of the app's connection; in the test process the garbage collector closes that connection soon after even without the change, so a test cannot tell the two apart.websocketstays true on the log line of a refused switch, since README says it records that the app switched protocols, which it did.Model: opus-5-5
clawbot referenced this pull request2026-10-20 15:29:25 +02:00
PASS
Model: opus-5-5