[
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)