https://issues.apache.org/bugzilla/show_bug.cgi?id=56299
--- Comment #7 from Edward Lu <[email protected]> --- Created attachment 31444 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31444&action=edit Return correct HTTP codes This patch fixes something I noticed that might be contributing to the problem. It's based on and includes Yann's patch (I couldn't figure out a good way to create a patch to be applied on top of his). The problem I noticed was that 500 was returned any time any closure of the WebSocket server occured. When reading from the server in ap_proxy_wstunnel_request(), anything except for a SUCCESS is considered an internal error, including a legitimate EOF. 500 is also returned if POLLERR is received when polling the server; this is a little suspect, since we're not the one having the issue, the WebSocket server is. That's not even considering the fact that the flag doing all this is named client_error, and that it's set in the section where we read from the server. It seemed like a good idea to just remove the client_error flag. However, doing so triggers another problem. Since ap_proxy_wstunnel_request() now returns OK, ap_discard_request_body() is run as part of the connection cleanup. On a normal Websocket close, this is fine, but something causes ap_discard_request_body() to block indefinitely on ap_get_brigade() when the connection is killed abormally (e.g. by SIGKILL on the server). I think it's something to do with either all the filters that get removed, or because the client's still hanging onto the request - I wasn't able to determine conclusively. The request's thread does eventually get killed by mod_reqtimeout. The client_error flag "solved" this problem, but in an obviously unsatisfactory way. I've removed it and instead set c->keepalive = AP_CONN_CLOSE, which tells the server that it doesn't need to run the additional processing after the handler returns. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
