Thanks.
On Wed, Aug 22, 2012 at 11:33 AM, Nick Mathewson wrote:
> Hm. Looking at how the output is used, I think that the tristate
> output format is probably a mistake. It wants to return both "did I
> read any data" *and* "am I now blocked", but the current interface
> can't express "I read s
Hello,
In libevent-2.0.19-stable, do_read can return 0 (stalled) when some
progress has been made reading. This can occur, for example, when
space[0].iov_len > 0 and the 2nd read attempt returns
SSL_ERROR_WANT_READ. Then consider_reading may not call
_bufferevent_run_readcb if no additional data a
On Mon, Apr 23, 2012 at 11:20 AM, Nick Mathewson wrote:
> And to offer dire warnings where Mark has offered beer: I will
> probably be merging this patch, or something quite like it, in the
> next 2.0.x-stable release, unless I can make it break or notice some
> bug in it. I'm really hoping that
Thanks for the help Mark.
On Sun, Jan 15, 2012 at 12:30 AM, Mark Ellzey wrote:
> evhtp_use_threads() is a connection pooler, each thread having its own
> event_base, and each connection being accepted to that threads evbase.
>
> in this case here, you are double threading, thus you break out of e
Thanks, Myk.
On Fri, Dec 23, 2011 at 2:35 AM, Myk Taylor wrote:
> From my tests, I found this was due to the SSL handshake not being
> renegotiated since the existing SSL bufferevent is being used for the new
> TCP connection. I sent up a patch earlier this month to address this issue.
My parti
On Thu, Dec 22, 2011 at 5:31 PM, Catalin Patulea wrote:
> Seems like bev_ssl flushes data to SSL_write and notifies back more
> eagerly than bev_sock, which is confusing evhttp_send_reply_end.
Thanks Catalin.
Based on your comments, I tried moving evhttp_write_buffer() above
evbuffer_add() and i
On Thu, Dec 22, 2011 at 3:29 PM, Hochhaus, Andrew
wrote:
> http.py is an example HTTP client that creates a persistent HTTP
> connection and sends two requests to each of the above handlers over a
> shared TCP connection
You can also reproduce the behavior in a web browser by running t
Hi,
While working on a comet http server, I have run into a problem where
the second request on a reused (persistent) TCP connection is not
processed by evhttp. Has anyone experienced behavior like this?
I created a minimal test case [1] which demonstrates that all of the
following must be true f
