Nick Mathewson [Fri, 26 Apr 2013 16:12:08 +0000 (12:12 -0400)]
Make all tests pass under EVENT_DEBUG_MODE=1
The fix was easy: the tests that were failing were those tests that
also enabled debug mode themselves. So, let them know when
EVENT_DEBUG_MODE is on, so they won't do that.
Azat Khuzhin [Thu, 21 Mar 2013 09:55:40 +0000 (13:55 +0400)]
Add new error_cb for actual reporting of HTTP request errors.
It is useful to know why you callback called with NULL (i.e. it failed),
for example if you set max_body with evhttp_connection_set_max_body_size()
you must know that it failed because of body was longer than this size.
Azat Khuzhin [Wed, 27 Mar 2013 16:15:46 +0000 (20:15 +0400)]
evdns: New flag to make evdns not prevent the event loop from exiting
Here is the brief description of problem:
When you are use evdns to resolve domains to IP adresses (see
./sample/dns-example) you loop never returns from event_base_dispatch(),
and because of this the program will never terminated.
Because existing programs may be depending on the old behavior, we
only apply the fix when evdns_base_new() is created with a new flag -
EVDNS_BASE_DISABLE_WHEN_INACTIVE.
(Commit message edited by Nick while squashing the branch.)
Nate Rosenblum [Tue, 5 Mar 2013 19:29:33 +0000 (11:29 -0800)]
Double-check next timeout when adding events
When resuming the system from a suspended state, the ev_timeout field
of a scheduled timer event may be in the past. This leads to
unexpected behavior when scheduling a short-duration timer event
immediately after returning from suspension, because the new event
does not land on top of the timeout minheap and so the event loop
(blocked on a possibly long-duration timeout) is not notified.
This patch checks for this condition and, if it obtains, notifies the
event loop.
Azat Khuzhin [Thu, 28 Feb 2013 13:19:44 +0000 (17:19 +0400)]
uri decode: fix for warning "use of uninitialised value"
This patch add check in evhttp_decode_uri_internal() that next 2 symbols
are exists in array of chars for decoding, if don't have two next 2
symbols don't try to decode '%FF'
avoid sign mismatch warning in openssl_hostname_validation.c
sample/openssl_hostname_validation.c: In function 'matches_common_name':
sample/openssl_hostname_validation.c:80: warning: comparison between signed and unsigned integer expressions
sample/openssl_hostname_validation.c: In function 'matches_subject_alternative_name':
sample/openssl_hostname_validation.c:124: warning: comparison between signed and unsigned integer expressions
use iSECPartners code to validate hostname in certificate
The problem is that if you go to a website whose certificate does not
match its hostname, it should fail. Try this in a web browser for
https://www.kegel.com/ for example. Your web browser will say the
certificate is for *.pair.com, not for www.kegel.com, and won't let
you visit it without clicking through a bunch of scary warnings.
However, prior to this commit, https-client was happy to fetch
https://www.kegel.com/ without complaining. That is bad. Now, with
this commit, it will properly complain, which is good:
pelletier@chives:~/src/libevent/sample$ ./https-client https://www.kegel.com/
Got 'MatchNotFound' for hostname 'www.kegel.com' and certificate:
/C=US/postalCode=15203/ST=Pennsylvania/L=Pittsburgh/street=Suite 210/street=2403 Sidney Street/O=pair Networks, Inc./OU=Provided by pair Networks, Inc./OU=PairWildcardSSL $250,000/CN=*.pair.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$
It will still succeed for sites with an exactly-matching certificate,
such as https://github.com/ and that is also good!
However, the problem is that the iSECPartners code doesn't handle
wildcards, which means we reject https://ip.appspot.com/ even though
it is perfectly legitimate, because we don't understand the wildcard:
ppelletier@chives:~/src/libevent/sample$ ./https-client https://ip.appspot.com/
Got 'MatchNotFound' for hostname 'ip.appspot.com' and certificate:
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$
So, we need to fix this. In other words, "to be continued..."
https-client was putting newlines at 256-byte boundaries
presumably this was meant to put a ">" before every line, but that
isn't what it does, since evbuffer_remove is simply returning
fixed-size chunks. So, when retrieving a document of more than 256
bytes (e. g. any nontrivial document), we got "> " and newlines thrown
in at very arbitrary places.
This made the difference between segfaulting and not segfaulting for
me when I run https-client, when I've built libevent using an OpenSSL
in a non-standard location.
Azat Khuzhin [Tue, 22 Jan 2013 22:45:32 +0000 (02:45 +0400)]
Fix ipv6 support for http. When URL contain domain, not IP address.
Before this patch socket created before domain was resolved, and it
always create with AF_INET (ipv4), but we must create socket only after
domain was resolved to understad which protocol family have domain
address.
Nick Mathewson [Sat, 12 Jan 2013 00:37:34 +0000 (16:37 -0800)]
When EWOULDBLOCK is not EAGAIN, treat it as equivalent to it
Acording to http://stackoverflow.com/questions/7003234/which-systems-define-eagain-and-ewouldblock-as-different-values
there are some older unixes that distinguish these error.s
projects / libevent / log