Folks, I'm using libevent in my project Metre: https://github.com/dwd/Metre
Metre deals with XMPP, which is a starttls-style protocol (sometimes). I would like to handle the case where a peer server sends the <stream:stream> open, the <starttls/>, and the TLS ClientHello all in the same packet. (I would prefer not to start a holy war on whether this is a good idea or not - let's just say it's very good in some obscure cases, and bad in others). I'm currently handling the <starttls/> in a fairly normal way - I insert a bufferevent_openssl_filter prior to negotiation commencing. But this means that data received after the <starttls/> command is received, and prior to the filter insertion, remains unhandled by the filter (and instead is passed through to the application). For obvious reasons this doesn't end well. Compounding this issue is a need to go hunting through DNS between the peer sending me <starttls/> and my initiating the negotiation (by sending the peer <proceed/>). (Code is at https://github.com/dwd/Metre/blob/master/src/starttls.cc should you need a good laugh). So: 1) I can't conceive a case where unhandled data in the read buffer of a bufferevent should not be reprocessed by a newly inserted filter. So I think this is a bug (or missing feature, or something). Loosely, I think that inside bufferevent_filter_new(), it should: if (input_buffer_is_not_empty) { call_input_callback(); } 2) It'd be great to workaround the bug (or missing feature, or deal with my unique insanity, or whatever). Is there any way I can coerce libevent into reprocessing that data into the new filter? (Faking a socket read would be fine). I imagine I could handle this by including a bufferevent pair somewhere, but that seems hideous and inefficient. Any pointers gratefully received. Dave. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
