[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[Libevent-users] evhttp client error handling



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.