On Wed, Mar 28, 2007 at 11:40:30AM +0100, David Reid wrote: > A while back there was a comment on this list that the ssl code should > be "ripped out" before the next release. There was no additional > information as to why, but that's OK.
Are you saying it *is* in a state ready for a 1.3 release, with the API/ABI constraints that entails? It went in as a (quote) "first dump", and has seen little improvement since then. Some API problems: - error handling is broken. lots of places return "-1" as an apr_status_t. - apr_ssl_socket_raw_error() breaks the abstraction and exposes the ABI of the SSL implementation - prototypes lack parameter names in many cases, hard to read - attempting to wrap every apr_socket_* function seems futile; why not just expose the apr_socket_t * pointer and let users deal with it directly? - having a "factory" keyed by "private key, cert, digest type" is obscure. digest type of what? Requiring "no pkey/cert == server" is also weird: clients can have private keys and certs too. - no cert verification if used for a client => SSL without the "security"; this needs API help to pass in the server name Some implementation problems: - is the OpenSSL code intended to be Unix-specific? It assumes apr_os_sock_t is an fd I guess, by passing it to SSL_set_fd - lots of argument validation (APR_EINVAL returns) which is non-standard for APR - does nothing really to support non-blocking writes as API claims joe
