https://bz.apache.org/bugzilla/show_bug.cgi?id=65886
--- Comment #11 from Archie Cobbs <[email protected]> --- Thanks guys, appreciate the fast response. I have two updates and a new question related to this. The updates are: 1 - Adding "ProxyWebsocketFallbackToProxyHttp off" does in fact work around the problem. 2 - Previously I said that setting "Timeout 300" also works around the problem, but that is not entirely accurate. What that does is simply change how long it takes for the particular problem I'm seeing to occur, from 60 seconds to 5 minutes. This is as you would probably expect. Here's my question: > As Rüdiger said, note that in 2.4.43 no timeout was enforced in > mod_proxy for websocket tunneling (neither ProxyTimeout nor Timeout, > so the timeout was actually infinite), your configuration worked > regardless of ProxyTimeout probably thanks to the heartbeat. The > above change was made precisely to honor a timeout while tunneling > without an ad hoc mechanism. OK this makes sense. Basically my web application is using websockets and sending a heartbeat every ~3 minutes. This websocket connection was previously being proxied by mod_proxy to Tomcat, and mod_proxy was not applying any particular timeout to that connection, so it would stay up indefinitely. But here's my question: isn't a websocket connection SUPPOSED to stay up indefinitely? Or at least, shouldn't any "timeout" value that is applied to that connection be an IDLE timeout rather than an ABSOLUTE timeout (measured from when the connection was started)? In other words, it seems to me like whatever mod_proxy was doing is more correct, at least in the scenario of a proxied websocket connection, than what mod_wstunnel is doing. Can you explain to me what I'm missing? Thanks. -- 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]
