Well, I would like to say it is possible, but it is isn't.
problem is in apache httpd that doesn't properly handle proxy + generic http upgrade.
they did add http-upgrade support for web sockets in 2.4 http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
but that is limited to only web sockets.
I would recommend you go with something like nginx WebSocket proxying where their impl is bit more generic.
Or maybe even try with mod_proxy_wstunnel but last time I tried it wasn't to successful with it.
Thanks for your reply, Tomaz. My shop won't run nginx so that's sadly not an option for me. I'll try to experiment with mod_proxy_wstunnel.
Does somebody have a hint how to configure Apache HTTPD with mod_proxy_wstunnel?
With 'proxyPass "/" "ws://localhost:8080"' I can access a normal web application on my Wildfly, but remote EJB access does not work (org.xnio.http.UpgradeFailedException: Invalid response code 200). Looks like my client gets Wildfly's welcome page as response.
Another good option, if you can get away with it, is to put WildFly in front of HTTPD instead of behind it. I haven't measured in many years but I would expect this arrangement to give you much better performance for your Java apps, and better proxy performance than you would have in your current situation (for me, HTTPD would sporadically produce errors on proxied requests under load no matter what I did with its configuration, but that was admittedly long ago).
My shop mandates Java EE servers handling sensitive data not to be directly accessible by clients.
Good answer! and it works, I already fixed this issue a while ago exactly by patching mod_proxy_wstunnel in order to catch the "jboss-remoting" headers.
Here is the much needed patch: http://pastebin.com/45LDGGLt
Just wanted to post an update that in WildFly 11, we will start supporting "normal" HTTP-based EJB invocation again which will work more easily with traditional reverse proxies and load balancers.
I could not even compile the .c file that you have pasted. gcc -c mod_proxy_wstunnel.c giving many errors. Do you have a .so file that is created for mod_proxy_wstunnel.c that has the patch ?
I finally managed to get it all working with nginx as load balancer for Wildfly JMS cluster. The http-remoting:// is working fine now.