Mads Toftum wrote:
On Tue, Jun 20, 2006 at 10:01:22PM +0200, Graham Leggett wrote:
A number of apps I have encountered that use SSL hide the original error
from you, replacing it with something vague and misleading, and you're
off on a wild goose chase.
Generally agreed, although knowing the horrors of openssl errors and how
difficult they can be to interpret, perhaps access to the raw error
along with a more generalised error would be the best compromise?
In fact, openssl has some of this already -
verify error:num=19:self signed certificate in certificate chain verify return:0
23457:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1052:SSL alert number 40
23457:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:226:
Guys, lets remember that we're planning for having more than just
openssl support, so while it's useful to consider it's not the only
thing we need to think about.
The idea was to have APR_ESSL mean that there was a problem that was ssl
related - then you call apr_ssl_socket_error() to get an os/library
specific code. apr_ssl_socket_error_string() would then get you a string
representation. I don't want to add any more error codes as they will
likely be different and not all applicable across all implementations.
Maybe I should have made this clearer but I did sort of think you guys
would trust me a little more?
david
