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.
Filip
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
