Mladen Turk wrote:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
