So I thought my solution was not good until I read you were getting the https
requests on port 8443 but ssl terminated.
Our configuration terminates ssl at the load balancer but forwards to port 80!
Which is why I couldn't get the normal options working for me.
John-Paul Ranaudo
Software Architect, Thomson Reuters
- sent via Blackberry
----- Original Message -----
From: Leinartas, Michael <michael.leinar...@orbitz.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Mon Jul 26 21:07:05 2010
Subject: Re: SSL terminated at load balancer, Http11Processor sends ssl
redirects to :80
holy. crap.
I cant believe I missed that config. It of course solves my problem, thanks
a bunch.
> From: Rainer Jung <rainer.j...@kippdata.de>
> Reply-To: Tomcat Users List <users@tomcat.apache.org>
> Date: Mon, 26 Jul 2010 16:30:02 -0500
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL terminated at load balancer, Http11Processor sends ssl
> redirects to :80
>
> On 26.07.2010 21:48, Leinartas, Michael wrote:
>> 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?
>
> Set proxyPort on the connector?
>
> See: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
