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]

Reply via email to