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]>
