[JBoss JIRA] (MODCLUSTER-723) 302 redirect not being forwarded when websockets are enabled
by Florian Morgan (Jira)
Florian Morgan created MODCLUSTER-723:
-----------------------------------------
Summary: 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
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)
3 years, 9 months
[JBoss JIRA] (MODCLUSTER-720) Allow mod_cluster listener to register at <Service> level rather than <Server> level
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/MODCLUSTER-720?page=com.atlassian.jira.p... ]
Radoslav Husar updated MODCLUSTER-720:
--------------------------------------
Fix Version/s: 1.4.3.Final
(was: 1.4.2.Final)
> Allow mod_cluster listener to register at <Service> level rather than <Server> level
> ------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-720
> URL: https://issues.redhat.com/browse/MODCLUSTER-720
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Core & Container Integration (Java)
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 2.0.0.Alpha1, 1.4.3.Final
>
>
> The container even handler needs to handle sequence of events that are sent when the listener is on the <Service> level as opposed to only handling the chain of events on the <Server> level. The intention is to only register that service the listener is registered on thus a service stub that only filers that service is then passed around.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (MODCLUSTER-711) Using "connectorPort" property fails if multiple services are configured in Tomcat
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/MODCLUSTER-711?page=com.atlassian.jira.p... ]
Paul Ferraro updated MODCLUSTER-711:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Using "connectorPort" property fails if multiple services are configured in Tomcat
> ----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-711
> URL: https://issues.redhat.com/browse/MODCLUSTER-711
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.4.0.Final
> Reporter: Tomas Briceno Fernandez
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 2.0.0.Alpha1, 1.4.2.Final
>
>
> If the Tomcat server configuration has several <service> elements and the mod_cluster listener is configured with *connectorPort* (most probably it is the same with *connectorAddress*), the configuration fails with these messages:
> {code}
> 06-Feb-2020 16:11:17.596 INFO [ContainerBackgroundProcessor[StandardEngine[TestEngine]]] org.jboss.modcluster.ModClusterService.connectionEstablished MODCLUSTER000012: TestEngine connector will use /127.0.0.1
> 06-Feb-2020 16:11:17.598 INFO [ContainerBackgroundProcessor[StandardEngine[TestEngine]]] org.jboss.modcluster.ModClusterService.establishJvmRoute MODCLUSTER000011: TestEngine will use 7bb39e02-96c0-3f8f-9fab-d464ad729cfe as jvm-route
> 06-Feb-2020 16:11:17.598 SEVERE [ContainerBackgroundProcessor[StandardEngine[TestEngine]]] org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren Exception invoking periodic operation:
> java.lang.RuntimeException: MODCLUSTER000047: No configured connector matches specified host:port (*:8081)! Ensure connectorPort and/or connectorAddress are configured.
> at org.jboss.modcluster.container.tomcat.ConfigurableProxyConnectorProvider.createProxyConnector(ConfigurableProxyConnectorProvider.java:89)
> at org.jboss.modcluster.container.tomcat.TomcatEngine.getProxyConnector(TomcatEngine.java:140)
> at org.jboss.modcluster.ModClusterService.connectionEstablished(ModClusterService.java:267)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:341)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:315)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:388)
> at org.jboss.modcluster.container.tomcat.TomcatEventHandlerAdapter.lifecycleEvent(TomcatEventHandlerAdapter.java:229)
> at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1174)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1396)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1368)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> My own code inspection suggests this is because of this loop :
> {code:title=org.jboss.modcluster.ModClusterService}
> @Override
> public void connectionEstablished(InetAddress localAddress) {
> for (Engine engine : this.server.getEngines()) {
> Connector connector = engine.getProxyConnector();
> InetAddress address = connector.getAddress();
> // Set connector address
> if ((address == null) || address.isAnyLocalAddress()) {
> connector.setAddress(localAddress);
> ModClusterLogger.LOGGER.detectConnectorAddress(engine, localAddress);
> }
> this.establishJvmRoute(engine);
> }
> this.established = true;
> }
> {code}
> The problem here is that the invocation of *engine.getProxyConnector()* will check if one and only one of the connectors in the engine matches the port configured by *connectorPort*. If more that one service is configured there will be multiple engines and this code will apply the previous condition to all of them. That is, to properly exit this method the port should exist in all engines, which will not happen normally.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (MODCLUSTER-722) Request header not forwarded to backend when websockets are enabled
by Gab K (Jira)
[ https://issues.redhat.com/browse/MODCLUSTER-722?page=com.atlassian.jira.p... ]
Gab K updated MODCLUSTER-722:
-----------------------------
Description:
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!
was:
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 to 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 uses 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 keeps 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!
> 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)
3 years, 9 months
[JBoss JIRA] (MODCLUSTER-722) Request header not forwarded to backend when websockets are enabled
by Gábor Kaposi (Jira)
Gábor Kaposi created MODCLUSTER-722:
---------------------------------------
Summary: 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: Gábor Kaposi
Assignee: Radoslav Husar
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 to 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 uses 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 keeps 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)
3 years, 9 months