https://bz.apache.org/bugzilla/show_bug.cgi?id=65294
--- Comment #17 from Yann Ylavic <[email protected]> --- So you have a SetEnv[If] or a RewriteRule setting "force-proxy-request-1.0" somewhere, right? This is the only way (I can think of) to make mod_proxy send this "GET /socket.io/1/websocket/UVTDmeB8ZH0F6kQpcaGG HTTP/1.0" request. However protocol/WebSocket Upgrade is not compatible with HTTP/1.0, from https://datatracker.ietf.org/doc/html/rfc7230#section-6.7: A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request. So mod_proxy_http won't send an "Upgrade: websocket" header with an HTTP/1.0 request, and the backend server without this header seems to simply close the connection immediately (with no response). In 2.4.46 and earlier, where websocket tunneling was handled by mod_proxy_wstunnel, there was some minimal HTTP protocol verification ony. Now (from 2.4.47) that all the upgrade forwarding mechanisms are handled by mod_proxy_http, there is more conformance with the HTTP protocol like this one, and notably/mostly the possibility to not upgrade/tunnel the connection if the origin server does not accept the upgrade (i.e. mod_proxy_http will continue with the HTTP protocol on subsequent requests/responses, until/unless the upgrade is really accepted by the origin server). In upcoming 2.4.48 there will be an opt-out (ProxyWebsocketFallbackToProxyHttp off) to let mod_proxy_wstunnel handle websocket tunneling like before 2.4.47 (i.e. disable the fallback to mod_proxy_http), but it's really safer to have mod_proxy_http do all the necessary HTTP checks actually So for your case I'd suggest that you simply do not "force-proxy-request-1.0", if possible (and it should be since Upgrade is not meant to be compatible with HTTP/1.0..). -- 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]
