* http: fix typo
* ws: fix comile error
On CentOS:
CC ws.lo
ws.c: In function 'get_ws_frame':
ws.c:244:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0; i < payload_len; i++) {
^
ws.c:244:3: note: use option -std=c99 or -std=gnu99 to compile your code
This adds few functions to use evhttp-based webserver to handle incoming
WebSockets connections. We've tried to use both libevent and libwebsockets in
our application, but found that we need to have different ports at the same
time to handle standard HTTP and WebSockets traffic. This change can help to
stick only with libevent library.
Implementation was inspired by modified Libevent source code in ipush project
[1].
[1]: https://github.com/sqfasd/ipush/tree/master/deps/libevent-2.0.21-stable
Also, WebSocket-based chat server was added as a sample.
Some GCC reports [1]:
/home/runner/work/libevent/libevent/http.c: In function ‘evhttp_make_header’:
/home/runner/work/libevent/libevent/http.c:503:14: error: ‘flags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
ev_uint16_t flags;
^~~~~
/home/runner/work/libevent/libevent/http.c: In function ‘evhttp_get_body’:
/home/runner/work/libevent/libevent/http.c:2354:14: error: ‘flags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
ev_uint16_t flags;
^~~~~
[1]: https://github.com/libevent/libevent/runs/7263518338?check_suite_focus=true#logs
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>
At the very beginning we reset the bufferevent fd (if bev has it), which
is not a good idea, since if user passes bufferevent with existing fd he
has some intention.
So we need to:
- use BEV_OPT_CLOSE_ON_FREE for default bufferevent_socket_new() (to
avoid manual shutdown/closee)
- drop getsockopt(SOL_SOCKET, SO_ERROR), since bufferevent already has
evutil_socket_finished_connecting_()
- drop supperior bufferevent_setfd(bev, -1) in
evhttp_connection_connect_()
Closes: #795
Refs: #875
@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
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>
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>
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
There are two possible ways of getting response from the server:
- processing existing bufferevent buffer
- reading from the socket (even after write() errored with -1, it is
still possible)
But we did not tried the first option, only the second one.
Fixes: http/read_on_write_error (on freebsd/osx)
We should not attemp to establishe the connection if there is retry
timer active, since otherwise there will be a bug.
Imagine next situation:
con = evhttp_connection_base_new()
evhttp_connection_set_retries(con, 2)
req = evhttp_request_new()
evhttp_make_request(con, req, ...)
# failed during connecting, and timer for 2 second scheduler (retry_ev)
Then another request scheduled for this evcon:
evhttp_make_request(con, req, ...)
# got request from server,
# and now it tries to read the response from the server
# (req.kind == EVHTTP_RESPONSE)
#
# but at this point retry_ev scheduled,
# and it schedules the connect again,
# and after the connect will succeeed, it will pick request with
# EVHTTP_RESPONSE for sending and this is completelly wrong and will
# fail in evhttp_make_header_response() since there is no
# "http_server" for this evcon
This was a long standing issue, that I came across few years ago
firstly, bad only now I had time to dig into it (but right now it was
pretty simple, by limiting amount of CPU for the process and using rr
for debug to go back and forth).
We have calls to the next functions but do not check return values,
though they can be invalid and it is better to show this somehow.
Also do bufferevent_setfd() first and only after it
bufferevent_enable()/bufferevent_disable() since:
a) it is more natural
b) it will avoid extra operations
c) it will not fail first bufferevent_enable() (this is the case for
buffbufferevent_async at least)
In this case we could add more information for issues like #709
Although this is not a problem, since bufferevent uses finalizers and
will free itself only from the loop (well this is not a problem if you
do not play games with various event_base in different threads) it
generates questions, so rewrite it in more reliable way.
Fixes: #712
Install conn_address of the bufferevent on incomping http connections
(even though this is kind of subsytem violation, so let's fix it in a
simplest way and thinkg about long-term solution).
Fixes: #510Closes: #595 (pick)
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 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
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
