Hi
Am 29.03.2011 12:28, schrieb Rainer Jung:
On 29.03.2011 12:07, Richard Levy wrote:
...
The current setup involves two intelligent load-balancers that
terminates SSL then hands over to Oracle 10g. The 10g stack has
custom Oracle versions of Apache which have configuration options not
found in standard Apache and appear to have made configuration
simpler. For instance, there is a "simulateHttps" directive that you
can give to a virtual host in Oracle Apache which does not exist in
the standard version. Using that option, we simply have 2 virtual
hosts defined in Apache, one for http traffic and one for https
traffic (with simulateHttps set to on). They both forward to OC4J and
it works fine.
You can achieve this with standard Apache and mod_jk esily to.
That's what we have in production:
1. Our "intelligent" Loadbalancer controls an additional
HTTP-Request-Header Front-End-Https (default off, on when using SSL).
2. Our Apache is one VirtualHost using the following block for SSL
detection:
<IfModule env_module>
# Fake SSL if Loadbalancer does SSL-Offload
SetEnvIf Front-End-Https "^on$" HTTPS=on
</IfModule>
Advantage:
1. as we use the same backend for ssl and non-ssl-traffic the session
affinity still works switching between HTTP and HTTPS
2. Reduced Apache configuration as we don't need to double VirtualHosts
for SSL
3. Transparent to the Java Applications. The Application won't notice
we've cheated :-)
With the new architecture we have two load-balancer which round-robin
to two Apache servers. These servers connect to two Tomcat servers
which are configured with a mod_jk loadbalancer using session
affinity. Through config we have separated HTTP& HTTPS traffic. We
have done this because the application needs to identify when it is
secure, which we do by simulating HTTP using settings in the connector
in the Tomcat server.xml. This is detailed further down.
Obviously we want to keep the same functionality on the Apache/Tomcat
stack, and also retain the termination of SSL at the load-balancer,
but are having trouble when the application switches to HTTPS. It
works fine if we have a single Tomcat instance running, but once the
2nd Tomcat instance is enabled, moving to HTTPS fails because a new
session is created.
I went only brievly thourgh your configuration list and communication
behavior, but thanks for the details!
I suggest you try the following:
- use only one connector per Tomcat instance, so
only one jvmRoute and only one worker per Tomcat
- let Apache via mod_jk inform the connector,
whether the request came via HTTP or (fake) HTTPS
- still do the redirect, but now because of only one connector you
have only one jvmRoute and only one worker per Tomcat.
So stickyness should work again.
How can Apache forward the HTTP vs. (fake) HTTPS info via mod_jk?
mod_jk automatically forwards the info whether the request was HTTPS.
When the application checks it, the Tomcat AJP connector retrieves the
info from what mod_jk forwarded it was and presents it to the
application. AJP itself is never encrypted.
Where does mod_jk get the info from? By default it checks an Apache
environment variable named "HTTPS", which is set by Apache whenever it
handles an HTTPS request.
You can also set the HTTPS environment variable by your Apache config,
but it is better to understand not to overload the meaning of the variable.
Instead:
- tell mod_jk to look for another, private variable which contains the
info whether the rquest was HTTP or (fake) HTTPS:
JkHTTPSIndicator MyHTTPSVariable
(you can choose the name MyHTTPSVariable)
- set the variable "MyHTTPSVariable" to "On" in the Apache
Virtual Host that receives your fake HTTPS requests
SetEnv JkHTTPSIndicator On
(for this mod_env must be enabled)
That's it :)
Guess that's cleaner then what we did. I'll put swapping HTTPS with
JkHTTPSIndicator on my todo-list.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
