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: r465303 - in /tomcat/tc6.0.x/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/
Date Wed, 18 Oct 2006 19:41:02 GMT
Mladen Turk wrote:
> Filip Hanik - Dev Lists wrote:
>> to eager to press send, that way the connector would have only on/off 
>> values, while the actual SSLEngine value neuron would be in the 
>> APRLifeCycleListener,
>> much cleaner, and all our connectors become consistent on that value
> Look, 

no need to get edgy :), your point is well taken.
> SSLEngine concept was derived from mod_ssl where SSLEngine
> toggles the usage of SSL/TLS (usually per VHost).
> We extended that (because we can not have per-vhost connectors)
> on the connector basis and added optional initialization for
> hardware SSL engines, and thus conceptually has nothing to
> do with the thing you are trying to use it for.
I understand the concept, but because the JNI API has a limitation of 
"one per VM" according to the code, then the connector is the wrong 
place to put it in.

> It would mean that the same directive (SSLEngine) would
> have two different meanings/purposes depending on the
> connector itself.
 > I would suggest that you came up with a different name
> (as well as documentation) that would properly describe
> what you are trying to do.
Lets expand on that suggestion then, lets come up with an attribute that 
goes across all three connectors, currently APR is using SSLEngine for 
dual purposes, including the "on" value which does the same as the Java 
connectors. So instead of having attributes with dual features, that 
always at some point become problems cause folks will want one feature 
but not the other, lets agree on something.

I have two suggestions
1. The SSLEngine attribute should be in the APR lifecycle listener, and 
not in the connector, since its static, I can't have more than one, so 
why do I have to define it more than once.
2. Add a SSLEnabled (or sslEnabled) attribute to the connector with only 
true/false values.

The goal from the beginning was consistency, and also support 
secure=true scheme=https even though its not actually running SSL, a 
pretty important feature.
I think this is a good step, as our connectors are/will be going in the 
same direction, not different directions based on who is working on them.


> Regards,
> Mladen.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message