tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r465675 - in /tomcat/tc6.0.x/trunk: conf/ java/org/apache/catalina/core/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/
Date Thu, 19 Oct 2006 17:31:11 GMT
Mladen Turk wrote:
> wrote:
>> SSLEngine is an attribute of the APR lifecycle listener to initialize 
>> the native SSL layer once per VM.
> I don't get it, really.
> Did you read my reply about:
> 1. scheme="https" secure="true"
> 2. scheme="https" secure="false"
> 3. scheme="http" secure="false"
> 4. scheme="http" secure="true"
got your reply, but we're not changing the logic on how these flags work.
Before my commit, the connectors would piggy back on these values to 
determine SSL or not,
it would be like introspect proxyPort="443" -> turn on SSL, an attribute 
should do one thing to be clear.

The scenario we are trying to achieve is this:
<Connector port="8443" scheme="https" secure="true" SSLEnabled="false"/>

The scheme and secure attributes are not in anyway related to each other.
scheme is just a string value returned so that the web app can construct 
URL correctly.
secure is a value so that Tomcat doesn't issue a redirect or a 403 error 
when <transport-guarantee>CONFIDENTIAL</transport-guarantee> is used.
secure can also be used by the application.

The simplest examples I have is when you use a hardware load balancer 
with SSL acceleration directly in front of Tomcat.
In the case that this SSL acceleration device has no way of telling you 
through HTTP headers that this request was secure or not
you might end up in a forever loop using only one connector and the 
webapp has the <transport-guarantee> element set.

So in this scenarion, setting up two HTTP connectors, one of them like 
above, the application will still constructs URLs correctly
and Tomcat will still handle the <transport-guarantee> element correctly.

There is no way doing this scenario if you intend to use the 
secure/scheme attributes with dual functionality.

> I would prefer we do that in a 'proper' way, because IMHO
> we can do what you need without introducing a third parameter,
> that BTW is meant for something else (Initializing hardware SSL Engine).
I believe the way it is now is the "proper" way:), why, cause no 
attribute has dual meanings and the consequences and limitations thereof.
> I agree that the APR implementation depends on that param for kicking
> the SSL on, but that's the APR implementation fault.
Yes, and that is now done once per VM, you can have as many APR SSL 
connectors as you want

Best Filip

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message