[JBoss JIRA] (MODCLUSTER-722) Request header not forwarded to backend when websockets are enabled
by Jason Jijón (Jira)
[ 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)
4 years, 2 months
- 1
- 0
[JBoss JIRA] (MODCLUSTER-723) 302 redirect not being forwarded when websockets are enabled
by Jason Jijón (Jira)
[ https://issues.redhat.com/browse/MODCLUSTER-723?page=com.atlassian.jira.p... ]
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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
- 1
- 0
- ← Newer
- 1
- Older →