]
Jason Jijón commented on MODCLUSTER-723:
----------------------------------------
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.
302 redirect not being forwarded when websockets are enabled
------------------------------------------------------------
Key: MODCLUSTER-723
URL:
https://issues.redhat.com/browse/MODCLUSTER-723
Project: mod_cluster
Issue Type: Bug
Components: Native (httpd modules)
Affects Versions: 1.3.14.Final
Reporter: Florian Morgan
Assignee: Radoslav Husar
Priority: Major
I'm having an issue with mod_cluster with JBoss EWS and JBoss EAP.
I have a JBoss EAP 7.1.6 server configured with JBoss EWS as a reverse proxy with
mod_cluster.
Normally everything works fine, I have no issue with this configuration.
When I add *WSUpgradeHeader NONE* I have a weird behaviour of EWS regarding the
forwarding of HTTP redirects.
The normal behaviour is the following:
# The client submit a request to this URL: [
http://ews-host:8080/arche]
# EWS forwards the request to JBoss EAP
# EAP replies with a 302 redirect
to [http://ews-host:8080/arche/|http://ews-host:8080/arche] (see the added */* at the end
of the request)
# EWS forwards the 302 redirect to the client.
# The client follows the redirect
to [http://ews-host:8080/arche/|http://ews-host:8080/arche]
# ... [The rest is fine and not significant to my problem]
When I add *WSUpgradeHeader NONE* the EWS no longer forwards the 302 redirect from the
EAP to the client, instead the redirect is *followed* by EWS to EAP and the redirected
content is forwarded to the client:
# The client submit a request to this URL: [
http://ews-host:8080/arche]
# EWS forwards the request to JBoss EAP
# EAP replies with a 302 redirect
to [http://ews-host:8080/arche/|http://ews-host:8080/arche] (see the added */* at the end
of the request)
# *(*) EWS follows the redirect and issue a request to JBoss EAP
to [http://ews-host:8080/arche/|http://ews-host:8080/arche]*
# *EAP replies with the content from /arche/*
# *EWS replies the redirected content (from 5.) to the client.*
(*) : I have no proof that EWS actually performs this request, maybe it comes from a
cache. But I do this hypthesis to simplify the problem.
I highlighted the changes in bold.
The problem here is that the URL stays [http://ews-host:8080/arche] instead of
being [http://ews-host:8080/arche/|http://ews-host:8080/arche].
It breaks all relative URLs from web pages.
Curiously, when the client issue 2 consecutive request, the first one follows the
incorrect behaviour, but the second one behaves normally.
It seems that EWS "remembers" the client host/ip and changes it behaviour to
the correct behaviour when it sees it again.
If I wait enough time, the incorrect behaviour is seen again.
Finally when I issue the requests from the same host (client=ews-host), the incorrect
behaviour is always seen. In that case EWS never forwards the redirect correctly.
I tried to work around using a *Redirect "/arche" "/arche/"*
configuration, but it doesn't change anything.
I can provide cURL commands to reproduce the problem if needed.
Do you know how can I have the correct behavour every time?
Thanks for the help.
PS : It seems to be linked to this
issue https://issues.redhat.com/browse/MODCLUSTER-722 but the case is not identical. Maybe
the cause of the problem is the same.