[
https://issues.redhat.com/browse/MODCLUSTER-722?page=com.atlassian.jira.p...
]
Jason Jijón commented on MODCLUSTER-722:
----------------------------------------
I have similar problem when using mod_cluster with proxy_wstunnel. I thought the problem
was related to using websocket, but then I make a test with two brand new
Wildfly.20.0.1.Final + Apache httpd 2.4.43 + mod_cluster 1.3.14 and I realize the problem
is not related to websockets, the problem is related to mod_cluster *with* wstunnel.
The details of my simple test:
* WildFly-1 has modcluster configured with default listener (http) ** and a single
deployment app1.war which only have a plain index.html
* WildFly-2 has modcluster configured with default listener (http) ** and a
single deployment app2.war which only have a plain index.html
* Apache Httpd has modcluster configured with _WSUpgradeHeader NONE_ and
using proxy_wstunnel_module.
Observed test results:
# When I request http://<apache IP>/app1 then result OK and the response comes from
WildFly-1.
# When I immediately request http://<apache IP>/app2 then result Not Found and *the
response comes from WildFly-1* but it should be WildFly-2
# If a wait 1 minute and again request http://<apache IP>/app2 then result is OK
and the response comes from WildFly-2.
# When I immediately request http://<apache IP>/app1 then result Not Found and *the
response comes from WildFly-2* but it should be WildFly-1 occurring the same problem in
2).
So my hypothesis is mod_cluster + wstunnel maintains the connection with client and
backend server for a while after the first request instead of choosing the right backend
depending on the context path primarily and not based on some "cache" or
something.
PD: When Apache Httpd is NOT using wstunnel, but proxy_http_module only, then the problem
dissapears and the apps respond from their respective backends. The only problem is
websocket is not supported in this mode and that is the primary reason for using
wstunnel.
Request header not forwarded to backend when websockets are enabled
-------------------------------------------------------------------
Key: MODCLUSTER-722
URL:
https://issues.redhat.com/browse/MODCLUSTER-722
Project: mod_cluster
Issue Type: Bug
Components: Native (httpd modules)
Affects Versions: 1.3.14.Final
Reporter: Gab K
Assignee: Radoslav Husar
Priority: Major
I'm having a Wildfly 20 cluster running in domain mode. I use Apache with mod_cluster
to serve as a load balancer and to make the web apps running on Wildfly available to the
public.
I have two goals to accomplish:
- The web apps should be served as https.
- Some web apps have websocket URLs, that should work from behind the proxy.
To enable web sockets I realized that I need to use http connection between Wildfly and
mod_cluster instead of ajp. This switch created a whole lot of issues. But ultimately I
managed to fix these by adding:
*ProxyPreserveHost On*
and
*RequestHeader set X-Forwarded-Proto "https"*
to the virtual hosts in Apache. The second one is important because as I wrote I'm
serving the web apps over https so Wildfly needs to know that the connection is https.
Otherwise the web apps think that the connection is http and use bad url formats. (I also
had to add *proxy-address-forwarding="true"* to the http listener in Wildfly for
this to work.)
Then I tried to solve the issue with web sockets. Because even with http connection they
didn't work. I enabled *proxy_wstunnel* module in Apache. Then I found these two
issues:
https://issues.redhat.com/browse/MODCLUSTER-580?_sscc=t
https://issues.redhat.com/browse/JBCS-425
Following the discussions from these issues I ended up building the latest version of
mod_cluster from git: version 1.3.14. Then added *WSUpgradeHeader NONE* to the
proxy_cluster.conf file. This solved the problem with web sockets, and the http pages are
also loading.
Now I'm having another issue. As I wrote above I added *RequestHeader set
X-Forwarded-Proto "https"* to let Wildfly know that the connection is https.
When I first open a https URL to a vhost using this header, the page opens perfectly. If I
now refresh the page, the page opens with unsecure http links.
(HttpServletRequest.getScheme() in Java web apps return "http")
*So the bug is that the second time I open the https URL, Wildfly clearly thinks that the
connection is http.*
This only happens when web sockets are enabled in mod_cluster config. Strangely if I wait
about a minute between the two page loads then the second page load is good, too. From the
mod_cluster status page I can see that the backend clients are connecting with url
"ws://..." instead of "http://...". Can it be that the connection
between mod_cluster and Wildfly is now through web sockets, that keep open for a minute,
and maybe the headers are only forwarded when the connection builds up? Is there a way to
fix this issue? Can the headers be forwarded for every requests somehow?
Thanks for the help!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)