|
|
|
// Copyright (c) 2015-2016 The Bitcoin Core developers
|
evhttpd implementation
- *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
10 years ago
|
|
|
// Distributed under the MIT software license, see the accompanying
|
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
|
|
|
#ifndef BITCOIN_HTTPSERVER_H
|
|
|
|
#define BITCOIN_HTTPSERVER_H
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <functional>
|
evhttpd implementation
- *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
10 years ago
|
|
|
|
|
|
|
static const int DEFAULT_HTTP_THREADS=4;
|
|
|
|
static const int DEFAULT_HTTP_WORKQUEUE=16;
|
|
|
|
static const int DEFAULT_HTTP_SERVER_TIMEOUT=30;
|
|
|
|
|
evhttpd implementation
- *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
10 years ago
|
|
|
struct evhttp_request;
|
|
|
|
struct event_base;
|
|
|
|
class CService;
|
|
|
|
class HTTPRequest;
|
|
|
|
|
|
|
|
/** Initialize HTTP server.
|
|
|
|
* Call this before RegisterHTTPHandler or EventBase().
|
|
|
|
*/
|
|
|
|
bool InitHTTPServer();
|
|
|
|
/** Start HTTP server.
|
|
|
|
* This is separate from InitHTTPServer to give users race-condition-free time
|
|
|
|
* to register their handlers between InitHTTPServer and StartHTTPServer.
|
|
|
|
*/
|
|
|
|
bool StartHTTPServer();
|
evhttpd implementation
- *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
10 years ago
|
|
|
/** Interrupt HTTP server threads */
|
|
|
|
void InterruptHTTPServer();
|
|
|
|
/** Stop HTTP server */
|
|
|
|
void StopHTTPServer();
|
|
|
|
|
|
|
|
/** Change logging level for libevent. Removes BCLog::LIBEVENT from logCategories if
|
|
|
|
* libevent doesn't support debug logging.*/
|
|
|
|
bool UpdateHTTPServerLogging(bool enable);
|
evhttpd implementation
- *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
10 years ago
|
|
|
|
|
|
|
/** Handler for requests to a certain HTTP path */
|
|
|
|
typedef std::function<bool(HTTPRequest* req, const std::string &)> HTTPRequestHandler;
|
evhttpd implementation
- *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
10 years ago
|
|
|
/** Register handler for prefix.
|
|
|
|
* If multiple handlers match a prefix, the first-registered one will
|
|
|
|
* be invoked.
|
|
|
|
*/
|
|
|
|
void RegisterHTTPHandler(const std::string &prefix, bool exactMatch, const HTTPRequestHandler &handler);
|
|
|
|
/** Unregister handler for prefix */
|
|
|
|
void UnregisterHTTPHandler(const std::string &prefix, bool exactMatch);
|
|
|
|
|
|
|
|
/** Return evhttp event base. This can be used by submodules to
|
|
|
|
* queue timers or custom events.
|
|
|
|
*/
|
|
|
|
struct event_base* EventBase();
|
|
|
|
|
|
|
|
/** In-flight HTTP request.
|
|
|
|
* Thin C++ wrapper around evhttp_request.
|
|
|
|
*/
|
|
|
|
class HTTPRequest
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
struct evhttp_request* req;
|
|
|
|
bool replySent;
|
|
|
|
|
|
|
|
public:
|
|
|
|
HTTPRequest(struct evhttp_request* req);
|
|
|
|
~HTTPRequest();
|
|
|
|
|
|
|
|
enum RequestMethod {
|
|
|
|
UNKNOWN,
|
|
|
|
GET,
|
|
|
|
POST,
|
|
|
|
HEAD,
|
|
|
|
PUT
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Get requested URI.
|
|
|
|
*/
|
|
|
|
std::string GetURI();
|
|
|
|
|
|
|
|
/** Get CService (address:ip) for the origin of the http request.
|
|
|
|
*/
|
|
|
|
CService GetPeer();
|
|
|
|
|
|
|
|
/** Get request method.
|
|
|
|
*/
|
|
|
|
RequestMethod GetRequestMethod();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the request header specified by hdr, or an empty string.
|
|
|
|
* Return an pair (isPresent,string).
|
|
|
|
*/
|
|
|
|
std::pair<bool, std::string> GetHeader(const std::string& hdr);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Read request body.
|
|
|
|
*
|
|
|
|
* @note As this consumes the underlying buffer, call this only once.
|
|
|
|
* Repeated calls will return an empty string.
|
|
|
|
*/
|
|
|
|
std::string ReadBody();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Write output header.
|
|
|
|
*
|
|
|
|
* @note call this before calling WriteErrorReply or Reply.
|
|
|
|
*/
|
|
|
|
void WriteHeader(const std::string& hdr, const std::string& value);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Write HTTP reply.
|
|
|
|
* nStatus is the HTTP status code to send.
|
|
|
|
* strReply is the body of the reply. Keep it empty to send a standard message.
|
|
|
|
*
|
|
|
|
* @note Can be called only once. As this will give the request back to the
|
|
|
|
* main thread, do not call any other HTTPRequest methods after calling this.
|
|
|
|
*/
|
|
|
|
void WriteReply(int nStatus, const std::string& strReply = "");
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Event handler closure.
|
|
|
|
*/
|
|
|
|
class HTTPClosure
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual void operator()() = 0;
|
|
|
|
virtual ~HTTPClosure() {}
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Event class. This can be used either as an cross-thread trigger or as a timer.
|
|
|
|
*/
|
|
|
|
class HTTPEvent
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
/** Create a new event.
|
|
|
|
* deleteWhenTriggered deletes this event object after the event is triggered (and the handler called)
|
|
|
|
* handler is the handler to call when the event is triggered.
|
|
|
|
*/
|
|
|
|
HTTPEvent(struct event_base* base, bool deleteWhenTriggered, const std::function<void(void)>& handler);
|
evhttpd implementation
- *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
10 years ago
|
|
|
~HTTPEvent();
|
|
|
|
|
|
|
|
/** Trigger the event. If tv is 0, trigger it immediately. Otherwise trigger it after
|
|
|
|
* the given time has elapsed.
|
|
|
|
*/
|
|
|
|
void trigger(struct timeval* tv);
|
|
|
|
|
|
|
|
bool deleteWhenTriggered;
|
|
|
|
std::function<void(void)> handler;
|
|
|
|
private:
|
evhttpd implementation
- *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
10 years ago
|
|
|
struct event* ev;
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif // BITCOIN_HTTPSERVER_H
|