User can define his own response method by calling
evhttp_set_ext_method_cmp() on the struct http, or
evhttp_connection_set_ext_method_cmp() on the connection.
We expose a new stucture `evhttp_ext_method` which is passed to the
callback if it's set. So any field can be modified, with some exceptions
(in evhttp_method_):
If the cmp function is set, it has the ability to modify method, and
flags. Other fields will be ignored. Flags returned are OR'd with the
current flags.
Based on changes to the #282 from: Mark Ellzey <socket@gmail.com>
From the server perspective the evhttp_response_phrase_internal() should
not be called with 0 before this patch, it will be called with
EVHTTP_REQ_UNKNOWN_ hence this patch should not change behavior.
Fixes: 68eb526d7b ("http: add WebDAV methods support")
Fixes: #789Fixes: #796
Reported-by: Thomas Bernard <miniupnp@free.fr>
Adds two new callbacks: "prepare" watchers, which fire immediately
before we poll for I/O, and "check" watchers, which fire immediately
after we finish polling and before we process events. This allows other
event loops to be embedded into libevent's, and enables certain
performance monitoring.
Closes: #710
To avoid possible confusion
But there is still one test that has some messages on windows:
main/methods
Because this test needs >1 of avaiable methods, otherwise it will warn.
Otherwise build errors will be ignored, i.e. if build fails but regress
binary exists (copied from artifacts) it will be runned instead of newly
compiled.
There is one more report that is false positive, see [1]:
"In bufferevent_openssl.c, pointer wm is dereferenced on line 871
before it is null checked on line 873."
[1]: https://github.com/libevent/libevent/issues/382#issuecomment-238081938
* fix-uchex-warnings:
evdns: do not check server_req twice
evrpc: do not check req twice
Fixes: #382
Reported by µchex:
"In evdns.c, pointer server_req is null checked on line 1289 after it
is dereferenced above. Since server_req was already null checked above
on line 1243, there is no risk of crashing and the only bug is the
redundant null check (and indentation) on line 1289.
"
- DNS_OPTION_NAMESERVERS_NO_DEFAULT
Do not "default" nameserver (i.e. "127.0.0.1:53") if there is no nameservers
in resolv.conf, (iff DNS_OPTION_NAMESERVERS is set)
- EVDNS_BASE_NAMESERVERS_NO_DEFAULT
If EVDNS_BASE_INITIALIZE_NAMESERVERS isset, do not add default
nameserver if there are no nameservers in resolv.conf (just set
DNS_OPTION_NAMESERVERS_NO_DEFAULT internally)
Fixes: #569
Due to regress linked with event and event_core (both of them includes
evthread.c) there will be two different evthread_id_fn_ variables under
mingw64:
evthread_id_fn_: &0x5294f20a8
evthread_id_fn_: &0x4ba0030a8
And because of this evthread_use_pthreads() can/will set one copy of
variables while evthread*() functions will access another, which will
break a lot of things (for example main/del_notify test).
Fixes: #792
And after this patch set default evbuffer max read via bufferevent is
16K not 4K.
Here is some numbers for the single max read in evbuffer impact:
function client() { becat "$@" | pv > /dev/null; }
function server() { cat /dev/zero | becat -l "$@"; }
Plain bufferevent:
- 40K
$ server -R $((40<<10)) & client -R $((40<<10))
700MiB/s
- 16K *default now*
$ server & client
1.81GiB/s
- 4K
$ server -R $((4<<10)) & client -R $((4<<10))
1.05GiB/s
With OpenSSL (-S):
- 40K *default now*
$ server -S -R $((40<<10)) & client -S -R $((40<<10))
900MiB/s
- 16K *default now*
$ server -S & client -S
745MiB/s
- 4K
$ server -S -R $((4<<10)) & client -S -R $((4<<10))
593MiB/s
So as you can see without openssl 16K is faster then 40K/4K, while for
openssl 40K is still faster then 16K (I guess that this is due to with
openssl SSL_read() more at at time, while with plain we have some
allocations splits in evbuffer and maybe due to some buffer in openssl)
* buffer-read-size:
sample/becat: bufferevent cat, ncat/nc/telnet analog
Adjust evbuffer max read for bufferevents
Maximum evbuffer read configuration
Fix leaks in error path of the bufferevent_init_common_()
Before this patch evbuffer always reads 4K at a time, while this is fine
most of time you can find an example when this will decrease throughput.
So add an API to change default limit:
- evbuffer_set_max_read()
- evbuffer_get_max_read()
And a notice that most of time default is sane.
By some reason gcc reports next error:
../http.c:3330:11: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
value = "";
Only under -Wwrite-strings, well this is logical, but this information
does not reflected in any documentation.
Follow-up: 8348b413 ("cmake: add various warning flags like autotools has")
f
This patch allows to change timeout for next events read/write/connect
separatelly, using new API:
- client:
evhttp_connection_set_connect_timeout_tv() -- for connect
evhttp_connection_set_read_timeout_tv() -- for read
evhttp_connection_set_write_timeout_tv() -- for write
- server:
evhttp_set_read_timeout_tv() -- for read
evhttp_set_write_timeout_tv() -- for write
It also changes a logic a little, before there was next fallbacks which
does not handled in new API:
- HTTP_CONNECT_TIMEOUT
- HTTP_WRITE_TIMEOUT
- HTTP_READ_TIMEOUT
And introduce another internal flag (EVHTTP_CON_TIMEOUT_ADJUSTED) that
will be used in evrpc, which adjust evhttp_connection timeout only if it
is not default.
Fixes: #692Fixes: #715
* evbuffer-empty-chain-handling:
buffer: do not rely on ->off in advance_last_with_data()
buffer: fix evbuffer_remove_buffer() with empty chain in front
test: verify content of the buffer in evbuffer/remove_buffer_with_empty*
advance_last_with_data() adjusts evbuffer.last_with_datap, and if we
will have empty chain in the middle advance_last_with_data() will stop,
while it should not, since while empty chains is not regular thing they
can pops up in various places like, and while I did not look through all
of them the most tricky I would say is:
evbuffer_reverse_space()/evbuffer_commit_space()
evbuffer_add_reference()
Test case from:
https://github.com/envoyproxy/envoy/pull/6062Fixes: #778
v2: keep last_with_datap really last with data, i.e. update only if
chain has data in it
In case we have empty chain (chain that do not have any data, i.e. ->off
== 0) at the beginning of the buffer, and no more full chains to move to
the dst, we will skip moving of this empty chain, and hence
last_with_datap will not be adjusted, and things will be broken after.
Fix this by not relying on ->off, just count if we have something to
move that's it.
Test case from:
https://github.com/envoyproxy/envoy/pull/6062Fixes: #774
Although `_GNU_SOURCE` can be defined as an arbitrary #define per the
glibc docs [1], it's best to define it in a manner consistent with the way
that autoconf defines it, i.e., `1`.
While this shouldn't matter in most cases, it does when the headers from
other projects follow the poorly defined GNU convention implemented by
autoconf and are included after the libevent's util.h header. An example
failure with clang, similar to the failure I encountered, is as follows:
```
$ printf "#define _GNU_SOURCE\n#define _GNU_SOURCE 1" | clang -c -x c -
<stdin>:2:9: warning: '_GNU_SOURCE' macro redefined [-Wmacro-redefined]
^
<stdin>:1:9: note: previous definition is here
^
1 warning generated.
```
This happened when compiling python [2] with a stale homebrew util.h file from
libevent (which admittedly would not happen in a correct libevent install, as the
header should be installed under /usr/local/include/event2/util.h). However, if
both headers had been combined (which is more likely), it would have failed as
shown above.
Removing the ad hoc definition unbreaks compiling python's pyconfig.h.in header
when included after util.h from libevent.
1. http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
2. https://github.com/python/cpython/blob/master/configure.ac#L126Closes: #773 (cherry-picked)
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
After we started to use kill() over raise() everything should work just
fine.
This reverts commit a86f89d333d870e6714bd28c695ba1774df3d7f5.
Fixed-in: 728c5dc1 ("Use kill() over raise() for raising the signal (fixes osx 10.14 with kqueue)")
Fixes: #747
On OSX 10.14+ the raise() uses pthread_kill() (verified with dtruss) and
by some reason signals that has been raised with pthread_kill() do not
received by kqueue EVFILT_SIGNAL.
While on OSX 10.11 the raise()/pthread_kill() uses plain kill() and
everything work just fine (linux also does the same, but instead of
kill() it uses tgkill())
Here is a simple reproducer that installs alarm to show that the signal
does not received by the kqueue backend:
https://gist.github.com/azat/73638b8e3b0fa563a20dadcca9e652a1
Refs: #747Fixes: #765
