Remy/Bill,
Ouch, that's one nasty hack. -1, please revert it.
There are callbacks to the processor to evaluate the SSL related attributes. If something is broken, this should be fixed, but using that pattern. I believe get/setSocket are useless, and the calls should be entierely removed.
I noticed the ActionHook calls to get SSL related attributes, however, CertificatesValve needs the SSLSocket in order to renegotiate an SSL handshake if the requested resource is from a webapp with this authentication constraint:
<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>
If the request was received through an SSL-enabled connector that does not enforce SSL client authentication, the handshake needs to be reinitiated, with client authentication enforced. In order to do that, CertificatesValve needs access to the SSLSocket, in order to call its startHandshake() method.
If the only purpose of CertificatesValve is to support the deprecated Http11Connector, which component is going to replace it and implement SSL handshake renegotiation?
Well, first of all, even if there's a bug or some missing feature, or anything, it's not a valid reason for adding a nasty hack. So please revert your patch.
It seems pretty clear to me that if you want to really implement that, you could add an additional callback (aka action), like the other SSL ones which are already there.
BTW, either there's client cert on the connector, or there isn't, right ? This seems best left to the lower level of the container, rather than trying to be too smart (and since it will be hard to make it consistent between JK and HTTP/1.1, I'm close to being -1 for trying to implement it). And yes, if JK can't be implemented in a compliant way, then I believe that part of the specification is broken and should be fixed.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
