Hi folks, while hacking up a patch for HTTPCLIENT-475, I stumbled about a few details. These are not urgent, but I'd like to write them down now before I forget something.
1) HostnameVerifier We have an interface with that name, and standard Java has one too in javax.net.ssl. Both define methods called verify() that check whether a hostname is acceptable with respect to presented certificates and such. Although they all share the same name, the standard Java method returns a boolean, while ours throw an exception if the verification fails. This is BAD. As in REALLY bad. Somebody gets used to the exception being thrown, then someday calls the standard Java method without noticing the difference, and a verification failure will just go unnoticed! Now I don't mind throwing an exception instead of returning a boolean. It allows for an error message that tells about the exact reason for the verification failure. But giving these methods the same name as the original method with a completely different usage pattern is not good. We must find a different name to point out the different usage pattern. Maybe check(...) or assert(...) or whatever, but not verify(...). 2) SocketFactory We have an interface with that name, and standard Java since 1.4 has one too in javax.net. The PlainSocketFactory implementation I modified for HTTPCLIENT-475 uses java.net directly, without the factory. The SSLSocketFactory uses the standard SSLSocketFactory. We could/should provide a non-SSL socket factory that uses the standard SocketFactory interface. I'm not sure whether this should be done directly in PlainSocketFactory, or whether we should leave the plain one as it is and have another one. 3) SecureSocketFactory The interface SecureSocketFactory is meant to create SSL socket connections. These are considered to be secure, while connections created directly from SocketFactory are considered insecure. I see two problems with this tie-in, where the second one is the bigger: - A SocketFactory might create secure connections by using for example native code. Since native code would not be able to layer a connection on top of a Java socket, the factory could not (fully) implement the SecureSocketFactory interface. - A SecureSocketFactory might create SSL connections that should not be considered secure, because security depends on the cipher suite that is chosen. I would prefer to untie those two aspects and introduce a method to check/indicate whether a specific connection is secure or not. The special thing about SecureSocketFactory is that it can layer a connection on top of an existing one. Renaming the interface to LayeredSocketFactory would be an option. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
