apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: additional error code
Date Tue, 20 Jun 2006 23:21:26 GMT
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

Mime
View raw message