Since [1] GET can have body, and hence for every incomming connection it
will print this error.
[1] db483e3b002b33890fc88cadd77f6fd1fccad2d2 ("Allow bodies for
GET/DELETE/OPTIONS/CONNECT")
Noticed-by: BotoX (irc)
Refs: #408
This is a refined version of the logic previously in #578
The rationale is that the consumer of sockets may wish to temporarily
delay accepting for some reason (e.g. being out of file-descriptors).
The kernel will then queue them up. The kernel queue is bounded and
programs like NodeJS will actually try to quickly accept and then close
(as the current behaviour before this PR).
However, it seems that libevent should allow the user to choose whether
to accept and respond correctly if the listener is disabled.
This is important, as otherwise clients can easily exhaust the file
descriptors available on a libevent HTTP server, which can cause
problems in other code which does not handle EMFILE well: for example,
see https://github.com/bitcoin/bitcoin/issues/11368Closes: #578 (patch cherry picked)
Fixes: #577
* evconnlistener-do-not-close-client-fd:
listener: cover closing of fd in case evconnlistener_free() called from acceptcb
Revert "Fix potential fd leak in listener_read_cb()"
This reverts commit a695a720cda892c270736d127333d73553842094.
@kgraefe:
"I believe that this commit is just wrong: if lev->cnt is not 1 after
the callback, new_fd will still never be closed in listener_read_cb().
So in that case it is the responsibility of the user's code to close
the file descriptor (which is fine). But why shouldn't it be in the
other case? And how does the user's code know?"
And I agree
'LIBEVENT_INCLUDE_DIRS' is properly initialized in 'LibeventConfig.cmake' as
'LibeventConfig.cmake.in' contains usage of 'LIBEVENT_CMAKE_DIR' and
'EVENT_INSTALL_INCLUDE_DIR' variables but not 'EVENT_CMAKE_DIR' and
'EVENT__INCLUDE_DIRS'.
Related typos are fixed.
Replaces reference in the http.h include header file to evhttp_get_decoded_uri
with evhttp_uridecode. There is no function called evhttp_get_decoded_uri.
This is the second hunk of the first patch
5ff8eb26371c4dc56f384b2de35bea2d87814779 ("Fix crashing http server when
callback do not reply in place")
Fixes: #567
I checked with nginx, and via it's lua bindings it allows body for all
this methods. Also everybody knows that some of web-servers allows body
for GET even though this is not RFC conformant.
Refs: #408
General http callback looks like:
static void http_cb(struct evhttp_request *req, void *arg)
{
evhttp_send_reply(req, HTTP_OK, "Everything is fine", NULL);
}
And they will work fine becuase in this case http will write request
first, and during write preparation it will disable *read callback* (in
evhttp_write_buffer()), but if we don't reply immediately, for example:
static void http_cb(struct evhttp_request *req, void *arg)
{
return;
}
This will leave connection in incorrect state, and if another request
will be written to the same connection libevent will abort with:
[err] ../http.c: illegal connection state 7
Because it thinks that read for now is not possible, since there were no
write.
Fix this by disabling EV_READ entirely. We couldn't just reset callbacks
because this will leave EOF detection, which we don't need, since user
hasn't replied to callback yet.
Reported-by: Cory Fields <cory@coryfields.com>
Since it can arrive after we disabled events in that bufferevent and
reseted fd, hence evhttp_error_cb() could be called after
SSL_RECEIVED_SHUTDOWN.
Closes: #557
Because it is mauvais ton to use binaries instead of normal packages
(like apt-get in debian, pacman in arch, and others).
Plus that link was borken and according to [1] OpenSSL do not ship
binaries officially.
And personally I don't think that this is not obvious that you need
openssl libraries to build libevent with it's support, and BTW you need
headers too (of course).
[1]: https://www.openssl.org/community/binaries.htmlFixes: #562
In function ‘send_a_byte_cb’:
test/regress.c:1853:2: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result [-Wunused-result]
(void) write(*sockp, "A", 1);
by default, the max buffer size is 16K and histeresis is at 50%, so
a bigger read is needed to unlock writes than you would expect from
other BSD (512 bytes)
this doesn't introduce any regression on FreeBSD 11.1, OpenBSD 6.1, NetBSD 7.1,
macOS 10.12.6 and of course DragonFlyBSD 4.8.1, and most of them show
a max pipe size of 64K, so the read call should drain them all regardless
of how conservative they are on the free pipe space they will require
(usually 512 bytes) before kevent reports the fd as ready for write.
I couldn't find a reference to which bug this code was trying to look for
and it seems to be there from the beginning of git history so it might be
no longer relevant.
Issue: #548
Detected using ThreadSanitizer, resolved by capturing the value
of ev_res in a local variable while the event is locked, then
passing that captured variable to the callback.
TSAN report:
I0728 14:35:09.822118 WARNING: ThreadSanitizer: data race (pid=815501)
I0728 14:35:09.822186 Write of size 2 at 0x7b2c00001bf2 by thread T80 (mutexes: write M1110835549570434736):
I0728 14:35:09.822248 #0 event_active_nolock_ libevent/event.c:2893:14 (0a2b90577e830d775300664df77d0b91+0x1fdab28)
I0728 14:35:09.822316 #1 event_active libevent/event.c:2858:2 (0a2b90577e830d775300664df77d0b91+0x1fdd10e)
I0728 14:35:09.822379 #2 Envoy::Event::TimerImpl::enableTimer(std::chrono::duration<long, std::ratio<1l, 1000l> > const&) envoy/source/common/event/timer_impl.cc:24:5 (0a2b90577e830d775300664df77d0b91+0x459fa0)
...
I0728 14:35:09.824146 Previous read of size 2 at 0x7b2c00001bf2 by main thread:
I0728 14:35:09.824232 #0 event_process_active_single_queue libevent/event.c:1646:33 (0a2b90577e830d775300664df77d0b91+0x1fdf83d)
I0728 14:35:09.824350 #1 event_process_active libevent/event.c (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824445 #2 event_base_loop libevent/event.c:1961 (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824550 #3 Envoy::Event::DispatcherImpl::run(Envoy::Event::Dispatcher::RunType) envoy/source/common/event/dispatcher_impl.cc:166:3 (0a2b90577e830d775300664df77d0b91+0x4576d9)
...
Fixes: #543 (pull-request)
It is a bit confusing to check against the result of EVUTIL_UPCAST(),
because it can return not NULL for NULL pointers, but for even though
with bufferevent we are fine (because bufferevent is the first field in
bufferevent_private), there are no checks for "bufev" in bufferevent's
API, so just remove it to make it generic.
Fixes: #542
Signed-off-by: Ivan Maidanski <i.maidanski@samsung.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
"chain" cannot be NULL here because we have at least one chain (we
handle empty buffer separatelly) and hence loop will be executed at
least once.
Link: 841ecbd961 (commitcomment-23631347)
Signed-off-by: Ivan Maidanski <i.maidanski@samsung.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
Currently it's not clear as to whether "first make it non-pending and
non-active" sentence requires user to take some action (e.g. call event_del(),
which event_free() already does internally) or just describes what this
function does from the developer point of view.
I cannot made it work without this, even though dumpbin shows that that symbol
exists in the event_core.dll, event_extra.dll failed to compile:
==> win: Creating library C:/vagrant/.cmake-vagrant/lib/Debug/event_extra.lib and object C:/vagrant/.cmake-vagrant/lib/Debug/event_extra.exp
==> win: http.obj : error LNK2001: unresolved external symbol _event_debug_logging_mask_ [C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj]
==> win: C:\vagrant\.cmake-vagrant\bin\Debug\event_extra.dll : fatal error LNK1120: 1 unresolved externals [C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj]
==> win: Done Building Project "C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj" (default targets) -- FAILED.
And dumpbin:
sh-4.1$ /cygdrive/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 12.0/VC/bin/amd64/dumpbin.exe /EXPORTS ./bin/Debug/event_core.dll
M
202 C9 00059A3C event_debug_logging_mask_ = _event_debug_logging_mask_
==> win: CMake Warning (dev) at CMakeLists.txt:782 (elseif):
==> win: Policy CMP0054 is not set: Only interpret if() arguments as variables or
==> win: keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
==> win: details. Use the cmake_policy command to set the policy and suppress this
==> win: warning.
==> win:
==> win: Quoted variables like "MSVC" will no longer be dereferenced when the policy
==> win: is set to NEW. Since the policy is not set the OLD behavior will be used.
==> win: This warning is for project developers. Use -Wno-dev to suppress it.
