mod_loadbalancer: HTTP/HTTPS switching broken
I've noticed what appears to be broken behaviour when using
mod_loadbalancer with Apache 2(.0.58) and SJSAS 8.1UR2 EE patch 09.
Apache sits in front of a cluster of appservers, and uses the distributed mod_loadbalancer (lbplugin) to proxy requests to the appservers.
One of our applications switches between HTTPS and HTTP at the end of session. It does so by making a call to HttpServletResponse.sendRedirect(), which should force the user to switch back to the insecured HTTP stream, from the HTTPS secured mode it is in (before the session closes).
When not using mod_loadbalancer, all works as expected and the user is returned to the HTTP session after this call. However, when mod_loadbalancer is working, despite the call to sendRedirect(HTTP), the plugin changes this to a redirect to the HTTPS stream.
This appears to be a bug with mod_loadbalancer and HTTP/HTTPS switching.
Note that the mod_loadbalancer has "https-routing=true" and "route-cookie-enabled=true".
While this problem exists switching (redirecting) from HTTPS to HTTP, it does seem to allow the initial switch from HTTP to HTTPS.
(Note sure if this is related at all to bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6438986)
[1263 byte] By [
tourtech] at [2007-11-26 8:16:10]
# 1
Hi,I would like to understand the problem clearly as your problem description does not seem to be complete one. The mentioned bug by you was already fixed in 8.1UR2 patch 9. Can you provide problem statement sothat I can comment on it?Thanks,-Balaji.
# 2
G'day Balaji.
I understand that the bug I quoted has been closed in the latest release, but I mentioned it as it was "similar" (not the same though!)
The exact problem is that when an application is running on an HTTPS port attempts to switch-back (to HTTP), mod_loadbalancer appears to have a bug when keeps redirecting it to the HTTPS stream.
ie. Our application switches protocols - from HTTPS to HTTP and mod_loadbalancer fails here in constantly (infinite loop) sending it incorrectly to the HTTPS feed when the application expressly switches back to plain old HTTP.
This can be demonstrated by running it on the application server directly - without the Apache/mod_loadbalancer frontend.
Without mod_loadbalancer, the application behaves as you'd expect it would, and the switching of protocols works.
ie. the application explicitly calls HttpServletResponse.sendRedirect("http://...") (notice the http - not https, yet when this is behind mod_loadbalancer, it refuses to send it to the http stream, and insists on sending it to "httpS://...".
As mentioned, this appears to be a bug with mod_loadbalancer, because:
- the behaviour is as expected without mod_loadbalancer (directly using appserver)
- the behaviour is as expected when the appserver cluster is behind Apache 2.2.2 with their own mod_proxy_balancer.
In slightly more detail, what's going on is the user's session is initially being served in secure mode (https), and the application sends a redirect to the insecure (http) port. When mod_loadbalancer is used, the redirect is incorrectly sent to the https stream, instead of the http feed.
I hope this explains the problem more clearly, but if not, let me know what you need to better understand it.
For what it's worth, we're using the very latest versions of each possible component (Appserver EE 8.1UR2 patch9, Apache 2.0.58 w/mod_loadbalancer or Apache 2.2.2 without mod_loadbalancer). Solaris 10 SPARC on a blazing-fast Sunfire T2000 ;)
# 3
Hi,
I can understand now better..
I don't think that it is a bug, but needs attention on the following:-
By default, the rewrite-location parameter is set to true to maintain backward compatibility with previous Application Server releases.
You must set the rewrite-location property with the following points in mind:
* If https-routing is true, rewrite-location should be false because the Application Server will be aware of HTTPS connections from the client.
* If https-routing is false, and auth-passthrough is enabled on the Application Server, then rewrite-location should be false because the Application Server will be aware of HTTPS connections from the client.
* If https-routing is false and auth-passthrough is not enabled on the Application Server, set the rewrite-location property to true because the load balancer will modify the protocol part of rewrite location suitably. That is, if the client is sending HTTPS requests, then the load balancer will redirect the client to a HTTPS enabled server instance. Similarly for HTTP requests.
==== Important point for your case =====
However, if the application needs to redirect HTTP to HTTPS or HTTPS to HTTP, you must set the rewrite-location parameter to false. <
So, you need set rewrite-location=false in loadbalancer.xml as application needs to redirect HTTPS to HTTP.
Plz let me know whether this resolves your problem or not.
Thanks,
-Balaji.
# 4
G'day Balaji,
Thank you!
The rewrite-location=false solved the problem.
To be honest, I'd totally forgotten about that option as I thought I'd specified all the options in my loadbalancer.xml config file already.
How embarrassing - one look at the DTD and it was there.
It's good to know it's not a bug in SJSAS 8. I suppose when things don't work as they say they should with SJSAS, the horrible days of Sun One Appserver 7 and all of its bugs make me doubt the newer version too.
While I was comfortable using the Apache 2.2 balancer, I'd probably prefer to stick with a Sun's own balancer.
Thanks again!
Corey.
# 5
Hi,
Good to know your opinion on our Sun Application Server.
But I would like to clarify again about this issue.
Actually the same Loadbalancer plugin from SunONE application 7 is being used by AS 8.1UR2x too.
This is not modified for any bugfixes in this module..
So, I would say that it will work like this only even in older release like Sun ONE application server.
Thanks,
-Balaji.
# 6
G'day BalajiNot quite sure precisely what you're getting at there.We're only using version 8.1EE (definitely not Sun One 7!), and the change you suggested is working fine.Cheers,corey.
