Weird connection issues with mod_proxy_wstunnel

[Marc Hörsken <info@xxxxxxxxxxxxxxxx>]

Hello everyone,

I am experiencing weird connection issues with mod_proxy_wstunnel. My Apache 2 web server is still running on Debian Wheezy, so I had to backport mod_proxy_wstunnel using the following patches:
https://github.com/mback2k/build-apache2.2-wstunnel

I compiled all mod_proxy* modules using these patches against the apache 2.2.22 sources provided by apt-get source apache2 on Debian Wheezy.

The following represents the relevant parts of my Apache 2 virtual host configuration for https://webgcal.uxnr.de

<VirtualHost ...:443>
        ServerName webgcal.uxnr.de
        ServerAdmin ...

        <IfModule mod_ssl.c>
                ...
        </IfModule>

        Alias /media/ /var/local/pyweb/project/webgcal/webgcal/_media/
        Alias /static/ /var/local/pyweb/project/webgcal/webgcal/_static/

        WSGIDaemonProcess webgcal user=webgcal group=webgcal processes=2 maximum-requests=100 python-path=/var/local/pyweb/project/webgcal:/var/local/pyweb/virtualenv/webgcal/lib/python2.7/site-packages
        WSGIProcessGroup webgcal
        WSGIScriptAlias / /var/local/pyweb/project/webgcal/webgcal/wsgi.py

        SetEnv DJANGO_SETTINGS_MODULE ...

        <Location /data/>
                ProxyPass ws://127.0.0.1:9001/data/ retry=0 disablereuse=On
                ProxyPassReverse ws://127.0.0.1:9001/data/
        </Location>
        <Location /settings.js>
                ProxyPass http://127.0.0.1:9001/settings.js retry=0 disablereuse=On
                ProxyPassReverse http://127.0.0.1:9001/settings.js
        </Location>
        ProxyPreserveHost On
        ProxyVia On
</VirtualHost>

Now once a browser has upgraded a connection from HTTP to WebSocket traffic, all traffic is proxied to the WebSocket-server at 127.0.0.1:9001. The problem is that the browser continues to use that upgraded WebSocket-connection for further HTTP-requests, for example to load the next page.

But since all traffic is forwarded to the WebSocket-server, the browser receives a 404 from there. So for some reason HTTP- and WebSocket-connections are not isolated properly. And Apache2 forwards URLs not beginning with /data or /settings.js to the Web-Socket-server.

Any ideas why this might happen?

I also tried the original patch to backport mod_proxy_wstunnel available here:

http://blog.cafarelli.fr/2013/04/backporting-apache-support-for-websockets-reverse-proxy-aka-getting-gateone-to-work-behind-apache/

I applied the patch using the following approach:

https://i.rationa.li/mark/note/2TWATCchRQGyMA0RlvZSQA

That approach was also the basis for my own approach that can be found in the Github repo mentioned before.

If you want to see the issue in action, you will have to signing to webgcal.uxnr.de and create a dummy calendar. This will enable the WebSocket-based status functionality of the dashboard.

Thanks in advance.

Best regards,

Marc