jean-frederic clere <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > A few issues remain: > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the > > existing JSSE code and my new code rely upon java.security.cert.* > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or > > less complete (less in the case of JSSE) certificate interfaces but > > they're of course different and we need a common interface presented > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new > > abstraction layer, which can't inherit from java.security.cert because > > that didn't exist in 1.1. This isn't a problem (Simple Matter of > > Programming) but is only worth doing if necessary. > > With JDK 1.1.x and AJP a null is returned. > With JDK 1.1.x should the CC be returned as a String? (I thought it was). It's certainly not in the JSSE code I was porting. That code didn't even compile without JDK 1.2.x.
from build.xml: <exclude name="**/util/net/SSLSocketFactory.java" unless="jdk12.present"/> In any case, we can do something far more sophisticated than a String if we want to, even with JDK 1.1.x. > > (II) How to expose SSLSupport? Currently Request has access to > > SSLSupport but it's not obvious (at least to me) how best to > > expose this to the rest of Tomcat and to JSPs/servlets. > > You have to use request.getAttribute() in the JSPs/servlets. Right, but that doesn't mean that we have to expose the SSLSupport interface. Instead we could break out each individual property we cared about into it's own attribute. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>