On Tue, Feb 19, 2013 at 9:40 PM, Jardel Weyrich wrote:
> 2) Call SSL_CTX_load_verify_locations passing the path of the CA
> certificates installed by the aforementioned package - generally
> /etc/ssl/certs/ca-certificates.crt
Nick, does this seem like a reasonable solution?
SSL_CTX_load_verify_lo
On Tue, Feb 19, 2013 at 3:05 PM, Nick Mathewson wrote:
>* It could sure use comments!
Can you be more specific? This all feels like a lot of boilerplate to
me. Parse the URL, initialize OpenSSL, create some bufferevents. I'm
not sure what more I can say that a reader of bufferevent.h,
bufferev
g' part. Seems related to the
occurrence of these on fds that time out.
On Tue, Feb 19, 2013 at 4:30 PM, Catalin Patulea wrote:
> On Tue, Feb 19, 2013 at 4:17 PM, Nick Mathewson wrote:
>> But the patch isn't quite optimal for that -- we should do the
>> bufferevent_setfd()
On Tue, Feb 19, 2013 at 4:17 PM, Nick Mathewson wrote:
> But the patch isn't quite optimal for that -- we should do the
> bufferevent_setfd() before we close the socket, not after. That way
> there's never a non-deleted event that refers to the fd.
The idea with doing the setfd there was in the c
Signed-off-by: Catalin Patulea
---
.gitignore| 1 +
sample/https-client.c | 207 ++
sample/include.am | 5 ++
3 files changed, 213 insertions(+)
create mode 100644 sample/https-client.c
diff --git a/.gitignore b/.gitignore
On Tue, Feb 19, 2013 at 11:49 AM, Nick Mathewson wrote:
> Could you be more specific about the good results, and how to
> reproduce them? Or how to reproduce/observe the undesired behavior?
> It would also be good to have an explanation of how the patch is
> supposed to work.
I had a lot of troub
[-cc: my personal email, added by mistake]
Ping. We've been seeing good results with this.
On Wed, Dec 19, 2012 at 11:05 AM, Catalin Patulea wrote:
> From: Catalin Patulea
>
> I'm curious what people think of a patch like this.. I've been seeing fds
> getting reu
From: Catalin Patulea
I'm curious what people think of a patch like this.. I've been seeing fds
getting reused and bufferevents adding/removing events on the underlying evmap
when they shouldn't be touching that fd anymore.
This patch seems to fix it but I haven't
On Sat, Jul 7, 2012 at 4:54 PM, Adrian Chadd wrote:
> .. what do other operating systems do?
BTW, glibc has a "rotate" option that load-balances across the list of
nameservers - but this option only applies when starting a new lookup
[1]. In the timeout case, a new nameserver is always tried [2].
On Sat, Jul 7, 2012 at 4:54 PM, Adrian Chadd wrote:
> Eg, what does the bind "libc" implementation of name lookups do? (ie,
> what user applications can do, not what BIND itself does.)
Any idea what Debian package has this implementation? The only
user-accessible resolver I can find in libbind-dev
Hi,
I'm interested in what happens when a freshly created evdns with more than
one nameserver encounters a timeout on the first request.
It seems evdns distinguishes between retransmits and reissues. Retransmits
are triggered by timeouts and always point to the same ns, chosen at
first-transmit t
imes rejects it).
For small patches like this, should I just paste the patch in the
message body? It would make it easier to glance at the patch, though
there's a possibility Gmail might mangle the text.
Catalin
From 429903e6385823d780631734a959ddae4401069c Mon Sep 17 00:00:00 2001
From: Catali
On Thu, Dec 22, 2011 at 5:12 PM, Catalin Patulea wrote:
> I'll be digging into this to try to figure out what's going on.
Seems like bev_ssl flushes data to SSL_write and notifies back more
eagerly than bev_sock, which is confusing evhttp_send_reply_end.
evhttp_send_reply_end tries
On Thu, Dec 22, 2011 at 4:55 PM, Hochhaus, Andrew
wrote:
> You can also reproduce the behavior in a web browser by running the
> server (main.cc), browsing to https://127.0.0.1:8889/ and then
> refreshing a few times (until one of the TCP connections is reused).
I can reproduce this too against ma
On Mon, Dec 19, 2011 at 5:34 PM, Haseeb Abdul Qadir
wrote:
>
Thanks for resending this on the mailing list.
> SSL_pending() ends up returning 0 in some cases even when the underlying BE's
> input buffer has data left to consume
This is exactly the condition I was afraid of back when 2aa036f was
On Thu, Nov 24, 2011 at 12:34 PM, Nick Mathewson wrote:
> I tidied the documentation a little in a44cd2b0205df; and fixed a
> couple of robustness issues in f3b89dec9eac2cf: you might want to
> check those out to make sure I didn't mess it up for you.
Still works fine here, thanks!
***
On Tue, Nov 22, 2011 at 7:18 PM, wrote:
> However if i a do hard reset(power off) of the machine running the client,
> it does not seem to work and I believe I am not getting a callback
> function for the event on the server.
I think the fundamental problem is distinguishing between 'hard reset'
.
From 9632ddb90393fcb4a8b537644d932e8eedd08c1c Mon Sep 17 00:00:00 2001
From: Catalin Patulea
Date: Mon, 21 Nov 2011 19:57:19 -0500
Subject: [PATCH 2/2] Allow users to set allow_dirty_shutdown
---
bufferevent_openssl.c| 23 ++-
include/event2/bufferevent_ssl.h | 16
it confuses evhttp. This patch makes bev_ssl additionally
set one of BEV_EVENT_{READING|WRITING}, as appropriate, when the
connection is closed.
From f7d21c69ac8b0c57fab6ba4c7afe2250c646c35e Mon Sep 17 00:00:00 2001
From: Catalin Patulea
Date: Mon, 21 Nov 2011 19:24:50 -0500
Subject: [PATCH 1/2] bev
On Wed, Nov 16, 2011 at 11:52 AM, Catalin Patulea wrote:
> - Peer sends two (small) SSL records in a row (perhaps in the same TCP
> segment)
> - fd becomes readable, libevent delivers read_cb to bev_ssl
> - bev_ssl calls SSL_read only once - does this read process only the
> first
A few things I forgot to mention:
Re: bev_ssl needing deferred or not, without OPT_DEFER_CALLBACKS,
https-client does not work for me. I haven't investigated.
Re: SSL_read loops. Consider the following scenario:
- Peer sends two (small) SSL records in a row (perhaps in the same TCP segment)
- fd
fail
Aborted
From 09e940ef9b71b612037e04b74f94879bfcbebd6a Mon Sep 17 00:00:00 2001
From: Catalin Patulea
Date: Wed, 16 Nov 2011 11:22:04 -0800
Subject: [PATCH] Add sample/https-client.c, an example of stacking evhttp as a client on top of bufferevent_ssl.
This reproduces an assert(req != NULL) in evhttp_conne
On Mon, Nov 14, 2011 at 11:17 AM, Mark Ellzey wrote:
> As far as I know, it doesn't. But I wrote this patch because if you are
> using a deferred bev with bulk incoming data, it never drops back into
> base_loop() until SSL_read() says there is nothing to read. This is due
> to the fact that your
Hi,
Why does bev_ssl require deferred callbacks?
Commit fc52dbac (see below) fixed an issue I was seeing where deferred
error_cb(EOF)s were confusing clients which had disabled EV_READs
(notably evhttp). If bev_ssl didn't require deferred cbs, the EOFs
would have stayed queued at the OpenSSL laye
24 matches
Mail list logo
