Michael,
Had the exact problem last week. Servlet spec changed to say engine must return
absolute paths. Since requests come in on port 80 or http the redirect will use
http scheme.
My quick fix was to change Tomcat source code to allow relative redirects. Thus
the browser handles building the whole path.
I did this fix due to time constraints and an app which has way too many
redirects to fix for the long term.
Just an FYI.
John-Paul Ranaudo
Software Architect, Thomson Reuters
- sent via Blackberry
----- Original Message -----
From: Leinartas, Michael <michael.leinar...@orbitz.com>
To: users@tomcat.apache.org <users@tomcat.apache.org>
Sent: Mon Jul 26 15:48:32 2010
Subject: SSL terminated at load balancer, Http11Processor sends ssl redirects
to :80
So I have what appears to be an obscure issue which is a consequence of our
architecture and am wondering if anyone's run into anything similar and if
my proposed solution is valid. So here's the background of our setup: We
run our tomcat by starting it within a simple container using the
catalina.startup.Embedded class and wiring up everything manually (i.e.
myembedded = new Embedded(new MemoryRealm()). We add two connectors, one
for http and one for https. The hardware load balancers we use send http
traffic to the http port and terminate ssl for https traffic, sending
unencrypted http traffic to the https port.
Make sense?
The way we've been able to do this is to create an HTTP/1.1 connector and
then mark it as secure and with an https scheme (so that request.getScheme()
and request.isSecure() return correctly to the webapp):
Connector c = new Connector("HTTP/1.1");
c.setSecure(true);
c.setScheme("https");
This is similar to how I've seen it done when googling around for this:
<Connector
port="8443"
protocol="HTTP/1.1"
scheme="https"
secure="true"
/>
Now this works fine *except* that when the application needs to send a
redirect to a relative path using
catalina.connector.Response.sendRedirect(String location), that method
converts the path to an absolute path
(catalina.connector.Response.toAbsolute) using the info from
request.getScheme(), request.getServerName(), and request.getServerPort().
It's the request.getServerPort() that's causing a problem. getServerPort is
implemented in coyote's Http11.*Processor classes to return port 80 if !ssl
or !sslEnabled (depending on which implementation). So in this case, the
method always returns port 80 (unless the url already has a port in it as it
does in dev). To actually flip the values of those booleans would require
setting the SSLEnabled property on the connector which is not what we want.
The end result is that if we have, say a secure login page that redirects
back to the home page on success, the user is redirected to
https://www.mysite.com:80/ which is invalid.
What I'm thinking is that getServerPort() should instead be checking to see
whether the scheme is http or https rather than looking whether the
processor is *actually* handling ssl or not. Is this a valid solution (i.e.
should I test and submit a patch) or is there a clean (or hell, even dirty)
alternative?
Thanks for your time
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
