Eric Rescorla wrote: > > > Eric Rescorla wrote: > > > jean-frederic clere <[EMAIL PROTECTED]> writes: > > > > Eric Rescorla wrote: > > > > 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. > > > > You are right but Ajp does not need JSSE (See Ajp13.java). > Correct. Currently it tries to convert it to a certificate but > uses a string if it can't find JSSE. We could easily arrange > that it did something cleverer than this. > > > > 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. > > > > It was a String in the past. > Right, but that's not exactly the most convenient interface. > > > > 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. > > > > Yes, but the question is what does it costs to setAttribute each time we process > > a request even if the servlet does not do a getAttribute. > Yes, this is a good point. This suggests that we ought to just > expose SSLSupport as a single attribute because it will be faster. > Is that what you're saying?
Yes, but now I am thinking that it only makes sense in mod_webapp (WARP) /mod_jk (Ajp14) where the SSL informations are requested in a separate dialog step between httpd and TC. > > It's actually easier for me to just expose SSLSupport but I want > to do whatever's most appropriate and that's why I sought people's > comments. The reason I wonder if we should set attributes is that > that's what Ajp currently does. > > > Another question is what about "javax.servlet.request.ssl_session" in PureSSL? > > Could we get it? (That is the SSL_SESSION_ID of mod_ssl). > I'll have to modify PureTLS to expose it but it's not inherently > difficult. Again, we'd want to add this to SSLSupport, I imagine. Yes > > -Ekr -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
