[Libevent-users] evhttp client error handling

[Patrick Pelletier <ppelletier@xxxxxxxxxx>]

I'm attempting to write an https client using evhttp and 
libevent_openssl.  It's not working, and I'm not so much concerned about 
that in itself (I'm sure I'm doing something wrong with OpenSSL; that is 
par for the course), but I'm trying to figure out how to get evhttp to 
tell me what the error is.  Or, in other words, how would I go about 
writing an https client with robust and verbose error handling using evhttp?

I'm using "master" on github (i. e. the bleeding edge of libevent), 
since the stable 2.0.x release series doesn't allow using evhttp and 
libevent_openssl together.

I based my https client off of this example:

http://archives.seul.org/libevent/users/Mar-2012/binGP2R6ys0C_.bin

Is there a better https client example I should be basing it off of instead?

Anyway, I've traced through things a bit, and here is the chain of 
events that is happening:

1) In bufferevent_openssl.c, conn_closed() is called with errcode = 5 
(SSL_ERROR_SYSCALL)

2) conn_closed() translates SSL_ERROR_SYSCALL into BEV_EVENT_ERROR

3) in http.c, evhttp_error_cb responds to BEV_EVENT_ERROR by calling 
evhttp_connection_fail_(evcon, EVCON_HTTP_EOF);

4) evhttp_connection_fail_ responds to EVCON_HTTP_EOF by calling my 
callback with NULL.

So, my concern is that at each step in the above sequence, some 
information is being lost, in that we start out with something at least 
semi-specific (SSL_ERROR_SYSCALL), but the only error notification my 
callback is getting is to be called back with NULL.  Is there something 
I'm missing here?  Is there some way my code could find out a more 
specific reason why it has been called with NULL?

Now, working in the opposite direction, there's also the issue that even 
if I knew the error was SSL_ERROR_SYSCALL, that's still not specific 
enough.  (But that is an OpenSSL issue.)  I'm amused by the definition 
of SSL_ERROR_SYSCALL:

#define SSL_ERROR_SYSCALL 5 /* look at error stack/return value/errno */

in that it would be nice if OpenSSL was more specific about which of 
those things to look at.  But I'm assuming the algorithm should be along 
the lines of "look at the error stack, and if that's empty, look at errno."

Anyway, the error stack does seem to be empty, because 
"ERR_print_errors_fp (stderr);" does not print anything.  So, that means 
I should look at errno, which is ENOTCONN.

I'm guessing here that there was some sort of error establishing the SSL 
connection, but we didn't notice or handle it, and forging ahead after 
the connection failed is what earned us ENOTCONN.

Assuming this hypothesis is correct, any thoughts on at what point 
libevent would have tried reporting that initial failure back to me, and 
what I would need to do to be notified of it?

Thanks for any insight here.  I can provide code if it helps, but it's 
really ugly/hacked up at the moment, and I'm more trying to understand 
the general idea behind error handling in evhttp, rather than finding 
the specific bug in my code.

--Patrick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.