Otherwise it breaks upload-artifacts:
Run actions/upload-artifact@v1
Uploading artifact 'ubuntu-18.04-cmake-NONE-build' from '/home/runner/work/libevent/libevent/build' for run #346
Uploading 1095 files
File error 'No such device or address' when uploading file '/home/runner/work/libevent/libevent/build/foo'.
...
Error: No such device or address
Error: Exit code 1 returned from process: file name '/home/runner/runners/2.282.1/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Artifact.PublishArtifact, Runner.Plugins"'.
There are no standard for encoding a unix socket in an url. nginx uses:
http://unix:/path/to/unix/socket:/httppath
The second colon is needed to delimit where the unix path ends and where
the rest of the url continues.
Signed-off-by: Sean Young <sean@mess.org>
@jcoffland:
"When the max connection limit is enabled and the limit is reached, the
server will respond immediately with 503 Service Unavailable. This can
be used to prevent servers from running out of file descriptors. This is
better than request limiting because clients may make more than one
request over a single connection. Blocking a request does not
necessarily close the connection and free up a socket."
* http-max_connections-pr-592:
test: cover evhttp max connections
Added evhttp max simultaneous connection limiting
@seleznevae:
"Added support for DNS requests via TCP. By default, requests are done
via UDP. In case truncated response is received new attempt is done
via TCP connection. Added 2 new macros DNS_QUERY_USEVC and
DNS_QUERY_IGNTC to force all requests to be done via TCP and to disable
switch to TCP in case of truncated responses.
Also added possibility for DNS server to listen and receive requests on
TCP port. Current implementation of TCP support in DNS server seems
rather preliminary and maybe changes after discussion and code review.
Fallback to TCP in case of truncated DNS requests is done automatically.
To imitate the old behaviour macros DNS_QUERY_IGNTC should be used. To
force all DNS requests to be done via TCP one should use the flag
DNS_QUERY_USEVC. Names DNS_QUERY_IGNTC, DNS_QUERY_USEVC were chosen to
imitate similar flags in c-ares and glibc."
Ok, interfaces looks good, merging to avoid stalling it for too long.
* evdns-tcp-pr-1004:
evdns: fix coding style issues
evdns: fix trailing whitespaces
evdns: bufferevent_setcb before bufferevent_free is redundant
evdns: Implement dns requests via tcp
The existing error pages are very basic and don't allow for
multi-lingual support or for conformity with other pages in a web site.
The aim of the callback functionality is to allow custom error pages to
be supported for calls to evhttp_send_error() by both calling
applications and Libevent itself.
A backward-incompatible change has been made to the title of error pages
sent by evhttp_send_error(). The original version of the function used
the reason argument as part of the title. That might have unforeseen
side-effects if it contains HTML tags. Therefore the title has been
changed to always use the standard status text.
An example of the error callback can be found in this
[version](https://github.com/libevent/libevent/files/123607/http-server.zip)
of the 'http-server' sample. It will output error pages with very bright
backgrounds, the error code using a very large font size and the reason.
Closes: #323 (cherr-picked from PR)
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>
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.
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
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.
This patch mark testcases that only fail under travis-ci/appveyor with
TT_RETRIABLE, since otherwise there is too much noise, other issues
(like failures under vagrant boxes) would be investigated separatelly.
linux (from travis-ci only):
- http/cancel_by_host_no_ns
- http/cancel_by_host_inactive_server
- http/cancel_by_host_ns_timeout
- http/cancel_by_host_ns_timeout_inactive_server
- thread/conditions_simple
- util/monotonic_prc_precise
- util/usleep
- main/del_wait
vagrant/ubuntu box (this is the only exception):
- thread/no_events
win32 (from appveyor only):
- main/active_later
- main/persistent_active_timeout
And we should use TT_RETRIABLE over TT_OFF_BY_DEFAULT/TT_SKIP when it
make sense.
But there is still "test-ratelim__group_lim" left.
EVHTTP_CON_READ_ON_WRITE_ERROR works only if an error already read from
the socket, but if we already got EPIPE on write we cannot read from the
socket anymore, and win32 does not guarantee that read will happens
before (although it happens from time to time).
In the referenced patch I just replaced callback with not expecting 417,
but like I already wrote, this is not always true (i.e. it is flacky).
Fixes: 3b581693ac1967f7f8d98491cb772a1b415eb4cd ("test/http:
read_on_write_error: fix it for win32")
One tricky bit is reply to the BIO_C_GET_FD command, since otherwise it
will try to close(0) and accepted bev in ssl/bufferevent_connect_sleep
will leak. Other seems more or less trivial.
This was done to make sure that for at least generic cases does not
leak (tricky cases was listed here nmathewson/Libevent#83).
And this will allow run ssl/.. with --no-fork
- http/basic_trailing_space -- covers cases when there is trailing space
after the request line (nginx handles this)
- http/simple_nonconformant -- covers non RFC3986 conformant URIs
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)
This is the second hunk of the first patch
5ff8eb26371c4dc56f384b2de35bea2d87814779 ("Fix crashing http server when
callback do not reply in place")
Fixes: #567
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>