aboutsummaryrefslogtreecommitdiff
path: root/src/httpserver.cpp
AgeCommit message (Collapse)Author
2015-10-20http: Restrict maximum size of request line + headersWladimir J. van der Laan
Prevent memory exhaustion by sending lots of data. Also add a test to `httpbasics.py`. Closes #6425
2015-09-28http: Force-exit event loop after predefined timeWladimir J. van der Laan
This makes sure that the event loop eventually terminates, even if an event (like an open timeout, or a hanging connection) happens to be holding it up.
2015-09-28http: Wait for worker threads to exitWladimir J. van der Laan
Add a WaitExit() call to http's WorkQueue to make it delete the work queue only when all worker threads stopped. This fixes a problem that was reproducable by pressing Ctrl-C during AppInit2: ``` /usr/include/boost/thread/pthread/condition_variable_fwd.hpp:81: boost::condition_variable::~condition_variable(): Assertion `!ret' failed. /usr/include/boost/thread/pthread/mutex.hpp:108: boost::mutex::~mutex(): Assertion `!posix::pthread_mutex_destroy(&m)' failed. ``` I was assuming that `threadGroup->join_all();` would always have been called when entering the Shutdown(). However this is not the case in bitcoind's AppInit2-non-zero-exit case "was left out intentionally here".
2015-09-28Make HTTP server shutdown more gracefulWladimir J. van der Laan
Shutting down the HTTP server currently breaks off all current requests. This can create a race condition with RPC `stop` command, where the calling process never receives confirmation. This change removes the listening sockets on shutdown so that no new requests can come in, but no longer breaks off requests in progress. Meant to fix #6717.
2015-09-21rpc: Split option -rpctimeout into -rpcservertimeout and -rpcclienttimeoutWladimir J. van der Laan
The two timeouts for the server and client, are essentially different: - In the case of the server it should be a lower value to avoid clients clogging up connection slots - In the case of the client it should be a high value to accomedate slow responses from the server, for example for slow queries or when the lock is contended Split the options into `-rpcservertimeout` and `-rpcclienttimeout` with respective defaults of 30 and 900.
2015-09-21http: Disable libevent debug logging, if not explicitly enabledWladimir J. van der Laan
Add a option "-debug=libevent" to enable libevent debugging for troubleshooting. Libevent logging is redirected to our own log.
2015-09-04[TRIVIAL] Fix typo: exactmath -> exactmatchpaveljanik
... but not yet in trivial tree
2015-09-03Fix race condition between starting HTTP server thread and setting EventBase()Wladimir J. van der Laan
Split StartHTTPServer into InitHTTPServer and StartHTTPServer to give clients a window to register their handlers without race conditions. Thanks @ajweiss for figuring this out.
2015-09-03Document options for new HTTP/RPC server in --helpWladimir J. van der Laan
2015-09-03Implement RPCTimerHandler for Qt RPC consoleWladimir J. van der Laan
Implement RPCTimerHandler for Qt RPC console, so that `walletpassphrase` works with GUI and `-server=0`. Also simplify HTTPEvent-related code by using boost::function directly.
2015-09-03evhttpd implementationWladimir J. van der Laan
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*. boost::asio is not part of C++11, so unlike other boost there is no forwards-compatibility reason to stick with it. Together with #4738 (convert json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with regard to compile-time slowness. - *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling is handled by libevent, a work queue (with configurable depth and parallelism) is used to handle application requests. - *Wrap HTTP request in C++ class*; this makes the application code mostly HTTP-server-neutral - *Refactor RPC to move all http-specific code to a separate file*. Theoreticaly this can allow building without HTTP server but with another RPC backend, e.g. Qt's debug console (currently not implemented) or future RPC mechanisms people may want to use. - *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL paths they want to handle. By using a proven, high-performance asynchronous networking library (also used by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided. What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests pass. The aim for now is everything but SSL support. Configuration options: - `-rpcthreads`: repurposed as "number of work handler threads". Still defaults to 4. - `-rpcworkqueue`: maximum depth of work queue. When this is reached, new requests will return a 500 Internal Error. - `-rpctimeout`: inactivity time, in seconds, after which to disconnect a client. - `-debug=http`: low-level http activity logging