The old evhttp_decode_uri() function would act as tough it was doing
an (illegal, undefined) decode operation on a whole URL at once, and
treat + characters following a ? as different from + characters
preceding one. But that's not useful: If you are decoding a URI
before splitting off query parameters, you are begging to fail as soon
as somebody gives you a value with an encoded & in it.
The new evhttp_uridecode() function takes an argument that says
whether to decode + signs. Both uridecode and uriencode also now
support encoding or decoding to strings with internal 0-valued
characters.
We already detected certain malformed queries, but we responded by
aborting the query-parsing process half-way through without telling
the user. Now, if query-parsing fails, no headers are returned, and
evhttp_parse_query returns -1.
When using the signal.c signal backend, Libevent currently only allows
one event_base to actually receive signals at a time. (This has been
the behavior since at least 1.4 and probably much earlier.) Now, we
detect and warn if you're likely to be racing about which signal goes
to which thread.
We also add a lock to control modifications of the evsig_base field,
to avoid race conditions like those found by Jason Toffaletti.
Also, more comments. Comments are good.
If threads queue callbacks while event_process_deferred_callbacks is
running, the loop may spin long enough to significantly skew timers.
A unit test stressing this behavior is also in this commit.
This reverts commit fab50488fcb741884ccdfa7b83643eac3e5c9cbf.
The function was, on reflection, not important enough to break the feature
freeze, since it's trivial to build on your own.
If there is an event-config.h in include/event2 (either because we
screwed up packaging like in 2.0.6-rc or because we previously tried
building with mingw and we didn't make distclean in the middle), we
want MSVC to find the one one in WIN32-Code/include/event2 first.
Found by Gilad Benjamini.
When we freed a bufferevent that was in a rate-limiting group and
blocked on IO, the process of freeing it caused it to get removed
from the group. But removing the bufferevent from the group made
its limits get removed, which could make it get un-suspended and in
turn cause its events to get re-added. Since we would then
immediately _free_ the events, this would result in dangling
pointers.
Fixes bug 3041007.
If you were to enable USE_DEBUG and slog through all 700+ MB of
debugging output, you'd find that one of the unit tests failed,
since it tested the debug logging code, but the string it expected
and the string it logged differed by a tab vs 2 spaces.
If the rate limit was low enough, then the echo_conns wouldn't finish
inside the 300 msec we allowed for them to close. Instead, count the
number of connections we have, and keep waiting until they are all
closed.
To be fair, when char can be signed, if toupper doesn't take negative
characters, toupper(char) is a very bad idea. So let's just use the
nice safe EVUTIL_TOUPPER instead. (It explicitly only upcases ASCII,
but we only use it for identifiers that we know to be ASCII anyway).
The bufferevent_connect_hostname test was specifying AF_INET, but the
gethostbyname test we were using to see what error to expect was using
PF_UNSPEC, leading to possible divergence of results.
