Nick Mathewson [Tue, 9 Nov 2010 16:43:47 +0000 (11:43 -0500)]
When closing a filtering bufferevent, clear callbacks on the underlying bufferevent
Previously, if BEV_OPT_CLOSE_ON_FREE wasn't set on a
bufferevent_filter or a filtering bufferevent_openssl, when we went
to free the filtering bufferevent, we'd leave the underlying
bufferevent unchanged. That's not so good, since the callbacks are
set to activate stuff in the filtering bufferevent that we're about
to free. Instead, set all the callbacks to NULL.
Felix Nawothnig [Thu, 4 Nov 2010 15:25:35 +0000 (11:25 -0400)]
Define enumerators for all HTTP methods, including PATCH from RFC5789
This patch defines enumerators for all HTTP methods that exist
(including PATCH introduced in RFC 5789).
It also makes them bit-masky (that's not a word, is it?), breaking
binary- but not source-code compatibility.
evhttp now stores a bitmask specifying for which methods requests to
dispatch and which ones to reject with "405 Method Not Allowed".
By default that's the ones we currently have (GET, POST, HEAD, PUT,
DELETE), thereby keeping functional compatibility (besides the minor
change that one of the other methods will now cause 405 instead of
400. But I believe that could even be considered a bug-fix).
evhttp is extended by evhttp_set_allowed_methods() with which the
user can change that bitmask.
no regressions here and my test-app still works. Haven't yet
actually tested any of the new methods.
What's obviously missing here is the special logic for the methods:
OPTIONS: We should be fine here - I believe our current dispatch
logic should work fine. Some convenience functions would be fine
though.
TRACE: I'm pretty certain we should never dispatch this to the
callbacks and simply implement the necessary functionality built-in.
CONNECT: Pretty straight-forward to implement (and considering the
framework in which we implement it very efficient too). Should
probably go built-in.
PATCH: Except for checking the RFC against our pre-dispatch logic
(there just might be some "MUST not have Some-Header" lurking
somewhere) there is nothing to be done here, this is completely up
to the user. Nothing to do.
Nick Mathewson [Wed, 3 Nov 2010 16:37:37 +0000 (12:37 -0400)]
Don't free evdns_request handles until after the callback is invoked
Previously, once the callback was scheduled, it was unsafe to cancel
a request, but there was no way to tell that. Now it is safe to
cancel a request until the callback is invoked, at which point it
isn't.
Nick Mathewson [Tue, 26 Oct 2010 16:09:20 +0000 (12:09 -0400)]
Fix bugs in posix thread-id calculation when sizeof(pthread_t) != sizeof(long)
When pthread_t was smaller, our calculated thread IDs would include
uninitialized RAM, and so our unit tests would fail because thread_ids
would never match one another.
When pthread_t was larger and alignment was big-endian, our calculated
thread IDs would only have the most significant bytes of the
pthread_t, when in practice all the entropy is in the low-order bytes.
Nick Mathewson [Tue, 26 Oct 2010 14:38:30 +0000 (10:38 -0400)]
Note that 2.0.9 will break the ABI, and make changes we were postponing.
We had to turn a couple of 32-bit size arguments into 64-bit arguments
or size_t arguments (since otherwise we would have had to do it post
2.0.x-stable, and that would be worse).
Nick Mathewson [Tue, 26 Oct 2010 02:36:23 +0000 (22:36 -0400)]
Correct logic for realigning a chain in evbuffer_add
The old logic was both too eager to realign (it would move a whole
chain to save a byte) and too reluctant to realign (it would only
realign when data would fit into the misaligned portion, without
considering the space at the end of the chain).
The new logic matches that from evbuffer_expand_singlechain: it only
realigns a chain when not much data is to be moved, and there's a
bunch of space to be regained.
Nick Mathewson [Tue, 26 Oct 2010 01:53:15 +0000 (21:53 -0400)]
Avoid missed-request bug when entire http request arrives before data is flushed
The trigger for starting to read the first line of a request used to
be, "When data has arrived and we're looking for the first line."
But that's not good enough: if the entire next request gets read
into our bufev->inbuf while we're still processing the current
request, we'll never see any more data arrive, and so will never
process it.
So the fix is to make sure that whenever we hit evhttp_send_done, we
call evhttp_read_cb. We can't call it directly, though, since
evhttp_send_done is reachable from the user API, and evhttp_read_cb
can invoke user functions, and we don't want to force everyone to
have reentrant callbacks. So, we use a deferred_cb.
Nick Mathewson [Mon, 25 Oct 2010 20:00:47 +0000 (16:00 -0400)]
Fix a bug where we would read too much data in HTTP bodies or requests.
We were using evbuffer_add_buffer, which moved the entire buffer
contents. But if we had a valid content_length, we only wanted to
move up to the amount of data remaining in ntoread. Our bug would
make us put our ntoread in the negative, which would in turn make us
read all data until the connection closed.
Nick Mathewson [Mon, 25 Oct 2010 18:29:30 +0000 (14:29 -0400)]
Make evbuffer_add_file take ev_off_t, not off_t
This change has no effect on non-windows platforms, since those
either define off_t to 64-bits, or allow you to decide whether
it should be 64-bits yourself via some LARGEFILE-like macro.
On Windows, however, off_t is always 32-bit, so it's a bad choice
for "file size" or "file offset" values. Instead, I'm adding
an ev_off_t type, and using it in the one place where we used
off_t to mean "the size of a file" or "an offset into a file" in the
API.
Nick Mathewson [Sun, 24 Oct 2010 15:51:14 +0000 (11:51 -0400)]
Simplify the logic for choosing EPOLL_CTL_ADD vs EPOLL_CTL_MOD
Previously, we chose "ADD" whenever old_events==new_events, (since
we expected the add to fail with EEXIST), or whenever old_events
was==0, and MOD otherwise (i.e., when old_events was nonzero and not
equal to new_events).
But now that we retry failed MOD events as ADD *and* failed ADD
events as MOD, the important thing is now to try to guess right the
largest amount of the time, since guessing right means we do only
one syscall, but guessing wrong means we do two.
When old_events is 0, ADD is probably right (unless we're hitting
the dup bug, when we'll fall back).
And when old_events is set and != new_events, MOD is almost
certainly right for the same reasons as before.
But when old_events is equal to new events, then MOD will work fine
unless we closed and reopened the fd, in which case we'll have to
fall back to the ADD case. (Redundant del/add pairs are more common
than closes for most use cases.)
This change lets us avoid calculating new_events, which ought to
save a little time in epoll.c
Nick Mathewson [Sun, 24 Oct 2010 15:38:29 +0000 (11:38 -0400)]
Fix a nasty bug related to use of dup() with epoll on Linux
Current versions of the Linux kernel don't seem to remove the struct
epitem for a given (file,fd) combo when the fd is closed unless the
file itself is also completely closed. This means that if you do:
fd = dup(fd_orig);
add(fd);
close(fd);
dup2(fd_orig, fd);
add(fd);
you will get an EEXIST when you should have gotten a success. This
could cause warnings and dropped events when using dup and epoll.
The solution is pretty simple: when we get an EEXIST from
EPOLL_CTL_ADD, we retry with EPOLL_CTL_MOD.
Unit test included to demonstrate the bug.
Found due to the patient efforts of Gilad Benjamini; diagnosed with
help from Nicholas Marriott.
Nick Mathewson [Wed, 20 Oct 2010 17:41:02 +0000 (13:41 -0400)]
Fix a 100%-CPU bug where an SSL connection would sometimes never stop trying to write
If an SSL connection becamse disabled or suspended before became open,
it could (under the right circumstances) wind up without ever getting
its write callback disabled.
The most correct fix is probably more subtle, and involves checking
all caseswhen a write callback is enabled or disabled. This fix is
more blunt, and explicitly checks whether the callback should have
been disabled at the end of the callback to prevent infinite looping.
Nick Mathewson [Thu, 14 Oct 2010 22:36:07 +0000 (18:36 -0400)]
Increment the version to 2.0.8-rc
NOTE: This is not the official release until I tag it. If you see
this commit, and you decide that Libevent 2.0.8-rc is now
finalized, you might get something besides 2.0.8-rc.