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
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>
windows has intptr_t instead of regular int.
Also tt_fd_op() had been introduced, since we cannot use tt_int_op() for
comparing fd, since it is not always int.
In 755fbf16c ("Add void* arguments to request_new and reply_new
evrpc hooks") this new functions had been introduced, but newer used,
what for? So let's use them.
And use it in places where event_debug() should be called (since it
requires access to "event_debug_logging_mask_" and in win32 it is
tricky).
One of this places that is covered by this patch is the test for
event_debug().
MinGW 32-bit 5.3.0 does not defines it and our appveyour [1] build
reports this instantly:
evutil.c: In function 'evutil_make_listen_socket_ipv6only':
evutil.c:392:40: error: 'IPV6_V6ONLY' undeclared (first use in this function)
return setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (void*) &one,
[1]: https://www.appveyor.com/docs/windows-images-software/#mingw-msys-cygwin
Another solution will be to use mingw64 which has it, but I guess we do
want that #ifdef anyway.
According to RFC3493 and most Linux distributions, default value is to
work in IPv4-mapped mode. If there is a requirement to bind same port
on same ip addresses but different handlers for both IPv4 and IPv6,
it is required to set IPV6_V6ONLY socket option to be sure that the
code works as expected without affected by bindv6only sysctl setting
in system.
See an example working with this patch:
https://gist.github.com/demirten/023008a63cd966e48b0ebcf9af7fc113Closes: #640 (cherry-pick)
Some implementations of bufferevents (for example openssl) can overrun
read high watermark.
And after this if user callback will not drain enough data it will be
suspended (i.e. it will not be runned again anymore).
This is not the expecting behaviour as one may guess, since in this case
the data will never be read. Hence once we detected that the watermark
exceeded (even after calling user callback) we will schedule the
callback again.
This also can be fixed in bufferevent openssl implementation (by
strictly limiting how much data is added to the read buffer according to
read high watermark), but since this data is already available (and in
memory) there is no point in doing so.
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)
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.
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.
But this is kind of hot-fix, we definitelly need more sane arc4random
compat layer.
Fixes: #488
Introduced-in: 6541168 ("Detect arch4random_addrandom() existence")
Since they are useful for debugging, and if autotools build them then
cmamke has to do this too, to make migration more simple.
And now:
- tests: uses shared libraries (since this is upstreams one)
- other binaries: uses static libraries
This removes next private config:
- EVENT__NEED_DLLIMPORT
This will remove openssl requirement if you don't use it (i.e. if you
not link with openssl_pthreads).
Plus it fixes some linking dependencies:
- libm required only for test-ratelim
And fix some coding style alignment issues.
Refs: #246
As pointed in https://github.com/libevent/libevent/pull/417#issuecomment-267860738
"code is unsafe because in evutil_date_rfc1123() the pointer to the
automatic variable struct tm cur is used outside the scope it defined."
Checked with `clang -fsanitize=address -fsanitize-address-use-after-scope`
and test that call evutil_date_rfc1123() with tm==NULL
Like in `sockaddr_in` structure in /usr/include/netinet/in.h
@azat: convert all other users (bench, compat, ..) and tweak message
Fixes: #178Fixes: #196
Refs: 6bf1ca78
Link: https://codereview.appspot.com/156040043/#msg4
By lingering close I mean something what nginx have for this name, by this term
I mean that we need to read all the body even if it's size greater then
`max_body_size`, otherwise browsers on win32 (including chrome) failed read the
http status - entity-too-large (while on linux chrome for instance are good),
and also this includes badly written http clients.
Refs: #321
v2: do this only under EVHTTP_SERVER_LINGERING_CLOSE
Otherwise if we will try to write more data than server can accept
(see `evhttp_set_max_body_size()` for libevent server) we will get `EPIPE` and
will not try to read server's response which must contain 400 error for now
(which is not strictly correct though, it must 413).
```
$ strace regress --no-fork http/data_length_constraints
...
connect(10, {sa_family=AF_INET, sin_port=htons(43988), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
...
writev(10, [{"POST / HTTP/1.1\r\nHost: somehost\r"..., 60}, {"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16324}], 2) = 16384
epoll_wait(5, [{EPOLLOUT, {u32=10, u64=10}}, {EPOLLIN, {u32=11, u64=11}}], 32, 50000) = 2
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = 16384
ioctl(11, FIONREAD, [32768]) = 0
readv(11, [{"POST / HTTP/1.1\r\nHost: somehost\r"..., 4096}], 1) = 4096
epoll_ctl(5, EPOLL_CTL_DEL, 11, 0x7fff09d41e50) = 0
epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLOUT, {u32=11, u64=11}}) = 0
epoll_wait(5, [{EPOLLOUT, {u32=10, u64=10}}, {EPOLLOUT, {u32=11, u64=11}}], 32, 50000) = 2
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = 16384
writev(11, [{"HTTP/1.1 400 Bad Request\r\nConten"..., 129}, {"<HTML><HEAD>\n<TITLE>400 Bad Requ"..., 94}], 2) = 223
epoll_ctl(5, EPOLL_CTL_DEL, 11, 0x7fff09d42080) = 0
shutdown(11, SHUT_WR) = 0
close(11) = 0
epoll_wait(5, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=10, u64=10}}], 32, 50000) = 1
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=13954, si_uid=1000} ---
epoll_ctl(5, EPOLL_CTL_DEL, 10, 0x7fff09d42010) = 0
shutdown(10, SHUT_WR) = -1 ENOTCONN (Transport endpoint is not connected)
close(10) = 0
write(1, "\n FAIL ../test/regress_http.c:3"..., 37
```
Careful reader can ask why it send error even when it didn't read
`evcon->max_body_size`, and the answer will be checks for `evcon->max_body_size
against `Content-Length` header, which contains ~8MB (-2 bytes).
And also if we will not drain the output buffer than we will send buffer that
we didn't send in previous request and instead of sending method via
`evhttp_make_header()`.
Fixes: http/data_length_constraints
Refs: #321
v2: do this only under EVHTTP_CON_READ_ON_WRITE_ERROR flag
And we can't make them continuous, since the latest is a public API, and
otherwise we will break binary compatibility.
Also extra check for EVHTTP_CON_PUBLIC_FLAGS_END, in case somebody forgot about
this (implementer I mean).
Refs: #182
Under the hood it's an unsigned rather than a signed type and whilst C
compilers are largely happy with this C++ compilers tend to be fussy
about class function signatures which makes C++ usage of libevent
problematic.
These types are not part of POSIX. As we only use them in a small number
of places, we'd better replace them by C standard types. This makes a
larger part of the code build for CloudABI.
In http the only case when when we could store it is when we already
connected, *but* if we are doing request using domain name, then we need
to do request to nameserver to get IP address, and this is handled by
bufferevent.
So when we have IP address (from nameserver) and don't have connection
to this IP address, we could already cache it to avoid extra DNS
requests (since UDP is slow), and we can't do this from http layer, only
from bufferevent.
* Fixed an issue with evutil_ersatz_socketpair_, listen_addr could all
be compared against with agarbage values. So just memset it before
using it anywhere.
* Nick might punch me in the face, but if we have stdint.h; (as in
EVENT__HAVE_STDINT_H is defined), might as well use those instead of
the manual [U]INT[X}_MAX/MIN muck in there now.
