Although bufferevent operations are threadsafe, sometimes you need
to make sure that a few operations on a single bufferevent will all
be executed with nothing intervening. That's what these functions
are for.
The current template...
<HTML><HEAD><TITLE>%s</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
Invalid method in request<P>
</BODY></HTML>
is highly confusing. The given title is easily overlooked and the
hard-coded content is just plain wrong in most cases (I really read
this as "the server did not understand the requested HTTP method)
This patch changes the template to include the error reason in the
body as well as in the header, and to infer the proper reason from
the status code whenever the reason argument is NULL.
This patch also removes a redundant evhttp_add_header from
evhttp_send_error; evhttp_send_page already adds a "Connection:
close" header.
Issue 1: autoconf gets accept when a header works properly with cpp
but not with cc. This was true of the sys/sysctl.h header on
openbsd. The fix: include sys/param.h (if present) when testing for
sys/sysctl.h
Issue 2: Somehow, autoconf's macro generation code is messed up on
some versions of openbsd (including mine, and other people's too) so
that instead of SIZEOF_VOID_P, it makes SIZEOF_VOID__.
evutil/util.h now works around that.
The "current_base" symbol was never actually declared in an exported
header; it's hideously deprecated, and it was the one remaining
exported symbol (fwict) that was prefixed with neither ev nor
bufferevent nor _ev nor _bufferevent.
codesearch.google.com turns up no actual attempts to use our
current_base from outside libevent.
The EVUTIL_CLOSESOCKET() macro required you to include unistd.h in your
source for POSIX. We might as well turn it into a function: an extra
function call is going to be cheap in comparison with the system call.
We retain the EVUTIL_CLOSESOCKET() macro as an alias for the new
evutil_closesocket() function.
(commit message from email by Nick and Sebastian)
This makes evprc setup more extensible, and helps with Shuo Chen's
work on implementing Google protocol buffers rpc on top of Libevent 2
evrpc.
This patch breaks binary compatibility with previous versions of
Libevent, since it changes struct evrpc and the signature of
evrpc_register_generic(). Since all compliant code should be calling
evrpc_register_generic via EVRPC_REGISTER, it shouldn't break source
compatibility.
(Code by Shuo Chen; commit message by Nick)
The evbuffer_remove() function copies data from the front of an
evbuffer into an array of char, and removes the data from the buffer.
This function behaves the same, but does not remove the data. This
behavior can be handy for lots of protocols, where you want the
evbuffer to accumulate data until a complete record has arrived.
Lots of people have asked for a function more or less like this, and
though it isn't too hard to code one from evbuffer_peek(), it is
apparently annoying to do it in every app you write. The
evbuffer_peek() function is significantly faster, but it requires that
the user be able to handle data in separate extents.
This patch also reimplements evbufer_remove() as evbuffer_copyout()
followed by evbuffer_drain(). I am reasonably confident that this
won't be a performance hit: the memcpy() overhead should dominate the
cost of walking the list an extra time.
These structures used TAILQ for the lists of events waiting on a
single fd or signal. But order doesn't matter for these lists; only
the order of the active events lists actually matters.
Generally, LIST_ can be a little faster than TAILQ_ for most
operations. We only need to use TAILQ_ when we care about traversing
lists from tail-to-head, or we need to be able to add items to the end
of the list.
Once, for reasons that made sense at the time, we had evdns.c use its
own logging subsystem with two levels, "warn" and "debug". This leads
to problems, since setting a log handler for Libevent wouldn't actually
trap these messages, since they weren't on by default, and since some of
the warns should really be msgs.
This patch changes the default behavior of evdns.c to log to
event_(debugx,warnx,msgx) by default, and adds a new (internal-use-only)
log level of EVDNS_LOG_MSG. Programs that set a evdns logging
function will see no change. Programs that don't will now see evdns
warnings reported like other warnings.
These were introduced and deprecated in the same version (2.0.1-alpha),
presumably in two-stage process. Everybody sane should be using
evsignal_assign() and evsignal_new() instead.
The different bufferevent implementations had different behavior for
their timeouts. Some of them kept re-triggering the timeouts
indefinitely; some disabled the event immediately the first time a
timeout triggered. Some of them made the timeouts only count when
the bufferevent was actively trying to read or write; some did not.
The new behavior is modeled after old socket bufferevents, since
they were here first and their behavior is relatively sane.
Basically, each timeout disables the bufferevent's corresponding
read or write operation when it fires. Timeouts are stopped
whenever we suspend writing or reading, and reset whenever we
unsuspend writing or reading. Calling bufferevent_enable resets a
timeout, as does changing the timeout value.
Previously, evdns was at the mercy of the user for providing a good
entropy source; without one, it would be vulnerable to various
active attacks.
This patch adds a port of OpenBSD's arc4random() calls to Libevent
[port by Chris Davis], and wraps it up a little bit so we can use it
more safely.
The 'flags' argument made sense when passed to
evdns_(base_)?parse_resolv_conf when it said which parts of the
resolv.conf file to obey. But for evdns_set_option(), it was really
silly, since you wouldn't be calling evdns_set_option() unless you
actually wanted to set the option. Its meaning was basically, "set
this to DNS_OPTIONS_ALL unless you want a funny surprise."
evdns_base_set_option was new in 2.0.1-alpha, so we aren't committed
to keeping it source-compatible.
when sending chunked requests via multiple calls to evhttp_send_reply_chunk,
the client may close the connection before the server is done sending. this
used to cause a crash.
we introduce a new function evhttp_request_get_connection() that allows the
server to determine if the request is still associated with a connection.
If it's not, evhttp_request_free() needs to be called explicitly or the user
can call evhttp_send_reply_end() which just frees the request, too.
We need these for Tor, and other projects probably need them too. Uses
include:
- Checking whether bandwidth is mostly-used, and only taking some
actions when there's plenty of bandwidth.
- Deducting some non-bufferevent activities from a rate-limit group.
It turns out that absolutely everything that was including
windows.h was doing so needlessly; our headers don't need it,
so we should just include winsock2.h (since that's where
struct timeval is defined).
Pre-2.0 code will use the old headers, which include windows.h
for them, so we aren't breaking source compatibility with 1.4.
This solves the bug where we were leaving WIN32_LEAN_AND_MEAN
defined, in roughly the same way that buying an automobile
solves the question of what to give your coachman for boxing
day.
This was never supposed to be an exposed API, so its name should have been
more like _EVUTIL_CHECK_FMT. But it was only used in one place, so let's
just eliminate it.
These are old aliases for event_get_fd and event_get_signal, and they
haven't been the preferred way of doing things since 2.0.1-alpha.
For a while, we made them use struct event if it was included, but call
event_get_(fd|signal) if it wasn't. This was entirely too cute.
We already emulate most of the other useful bits of stdint.h, and
we seem to have started to use uintptr_t in a few places throughout
the code. Let's make sure we can continue to do so even on backwards
platforms that don't do C99.
Right now it only catches cases where we aren't initializing events,
or where we are re-initializing events without deleting them first.
These are however shockingly common.
Nothing in evrpc.c was using rpc_compat.h, so it's best to take it
out, especially since it polluted our build process with GCC variadic
macros.
While we're at it, this patch puts an extra restriction on when the
variadic macros in rpc_compat.h are defined. Not only must GCC be the
compiler, but GCC must not be running in -ansi mode.
