Ah yeah, initially I thought this wouldn't work for me since - I'm guessing
here, haven't tested - setting proxyPort will screw up the same redirect
requests if i were to hit :8443 directly (i.e. in dev) but this isn't a
problem with this configuration since a browser cant hit
https://myserver:8443 anyway - The browser is trying to terminate ssl which
isn't enabled on the connector, and trying http on :8443 wont work either
since the connector's scheme is set to https.
Thanks again guys, it's been enlightening
> From: "john.rana...@thomsonreuters.com" <john.rana...@thomsonreuters.com>
> Reply-To: Tomcat Users List <users@tomcat.apache.org>
> Date: Mon, 26 Jul 2010 20:48:19 -0500
> To: "users@tomcat.apache.org" <users@tomcat.apache.org>
> Subject: Re: SSL terminated at load balancer, Http11Processor sends ssl
> redirects to :80
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
