On Mon, Jul 22, 2019 at 08:17:54PM +0200, Steffen Christgau wrote: > Based on what I have seen in the le-proxy example and the zlib > regression test, my impression was that it would be sufficient to > replace the bufferevent of the (openssl) socket with the one returned by > the filter and use the original bufferevent as underlying bev. > > This is what I've done in the https-client example. I added a "null" > filter for both incoming and outgoing data and which passes data through > but does nothing else except printing a message that the filter was > invoked. You can find an according patch attached to this mail. > However, it does not work as expected. With the patch, the client is > broken. The TCP connection to the HTTP(s) server is still established, > but no data is transferred and the filters aren't invoked. For accesses > to HTTPS, the TLS handshake is done, but again no filter is invoked and > no HTTP traffic is observed.
Well the patch does not work correct, and if you will take a closer look into it you will see that filter_in/filter_out will not be used for https. Anyway even after rewriting it correctly it still did not work right, I will get back once I will find out what is going on. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
