Hush Full Node software. We were censored from Github, this is where all development happens now. https://hush.is
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

641 lines
21 KiB

// Copyright (c) 2009-2010 Satoshi Nakamoto
// Copyright (c) 2009-2014 The Bitcoin Core developers
3 months ago
// Copyright (c) 2016-2024 The Hush developers
// Distributed under the GPLv3 software license, see the accompanying
// file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
/******************************************************************************
* Copyright © 2014-2019 The SuperNET Developers. *
* *
* See the AUTHORS, DEVELOPER-AGREEMENT and LICENSE files at *
* the top-level directory of this distribution for the individual copyright *
* holder information and the developer policies on copyright and licensing. *
* *
* Unless otherwise agreed in a custom licensing agreement, no part of the *
* SuperNET software, including this file may be copied, modified, propagated *
* or distributed except according to the terms contained in the LICENSE file *
* *
* Removal or modification of this copyright notice is prohibited. *
* *
******************************************************************************/
#include "primitives/block.h"
#include "primitives/transaction.h"
#include "main.h"
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
9 years ago
#include "httpserver.h"
#include "rpc/server.h"
#include "streams.h"
#include "sync.h"
#include "txmempool.h"
#include "util/strencodings.h"
#include "version.h"
#include <boost/algorithm/string.hpp>
#include <boost/dynamic_bitset.hpp>
#include <univalue.h>
using namespace std;
static const size_t MAX_GETUTXOS_OUTPOINTS = 15; //allow a max of 15 outpoints to be queried at once
enum RetFormat {
RF_UNDEF,
RF_BINARY,
RF_HEX,
RF_JSON,
};
static const struct {
enum RetFormat rf;
const char* name;
} rf_names[] = {
{RF_UNDEF, ""},
{RF_BINARY, "bin"},
{RF_HEX, "hex"},
{RF_JSON, "json"},
};
struct CCoin {
uint32_t nTxVer; // Don't call this nVersion, that name has a special meaning inside IMPLEMENT_SERIALIZE
uint32_t nHeight;
CTxOut out;
ADD_SERIALIZE_METHODS;
template <typename Stream, typename Operation>
inline void SerializationOp(Stream& s, Operation ser_action)
{
READWRITE(nTxVer);
READWRITE(nHeight);
READWRITE(out);
}
};
extern void TxToJSON(const CTransaction& tx, const uint256 hashBlock, UniValue& entry);
extern UniValue blockToJSON(const CBlock& block, const CBlockIndex* blockindex, bool txDetails = false);
extern UniValue mempoolInfoToJSON();
extern UniValue mempoolToJSON(bool fVerbose = false);
extern void ScriptPubKeyToJSON(const CScript& scriptPubKey, UniValue& out, bool fIncludeHex);
extern UniValue blockheaderToJSON(const CBlockIndex* blockindex);
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
9 years ago
static bool RESTERR(HTTPRequest* req, enum HTTPStatusCode status, string message)
{
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
9 years ago
req->WriteHeader("Content-Type", "text/plain");
req->WriteReply(status, message + "\r\n");
return false;
}
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
9 years ago
static enum RetFormat ParseDataFormat(vector<string>& params, const string& strReq)
{
boost::split(params, strReq, boost::is_any_of("."));
if (params.size() > 1) {
for (unsigned int i = 0; i < ARRAYLEN(rf_names); i++)
if (params[1] == rf_names[i].name)
return rf_names[i].rf;
}
return rf_names[0].rf;
}
static string AvailableDataFormatsString()
{
string formats = "";
for (unsigned int i = 0; i < ARRAYLEN(rf_names); i++)
if (strlen(rf_names[i].name) > 0) {
formats.append(".");
formats.append(rf_names[i].name);
formats.append(", ");
}
if (formats.length() > 0)
return formats.substr(0, formats.length() - 2);
return formats;
}
static bool ParseHashStr(const string& strReq, uint256& v)
{
if (!IsHex(strReq) || (strReq.size() != 64))
return false;
v.SetHex(strReq);
return true;
}
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
9 years ago
static bool CheckWarmup(HTTPRequest* req)
{
std::string statusmessage;
if (RPCIsInWarmup(&statusmessage))
return RESTERR(req, HTTP_SERVICE_UNAVAILABLE, "Service temporarily unavailable: " + statusmessage);
return true;
}
static bool rest_headers(HTTPRequest* req,
const std::string& strURIPart)
10 years ago
{
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
9 years ago
if (!CheckWarmup(req))
return false;
10 years ago
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
10 years ago
vector<string> path;
boost::split(path, params[0], boost::is_any_of("/"));
if (path.size() != 2)
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
9 years ago
return RESTERR(req, HTTP_BAD_REQUEST, "No header count specified. Use /rest/headers/<count>/<hash>.<ext>.");
10 years ago
long count = strtol(path[0].c_str(), NULL, 10);
if (count < 1 || count > 2000)
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
9 years ago
return RESTERR(req, HTTP_BAD_REQUEST, "Header count out of range: " + path[0]);
10 years ago
string hashStr = path[1];
uint256 hash;
if (!ParseHashStr(hashStr, hash))
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
9 years ago
return RESTERR(req, HTTP_BAD_REQUEST, "Invalid hash: " + hashStr);
10 years ago
std::vector<const CBlockIndex *> headers;
10 years ago
headers.reserve(count);
CDataStream ssHeader(SER_NETWORK, PROTOCOL_VERSION);
10 years ago
{
LOCK(cs_main);
BlockMap::const_iterator it = mapBlockIndex.find(hash);
const CBlockIndex *pindex = (it != mapBlockIndex.end()) ? it->second : NULL;
while (pindex != NULL && chainActive.Contains(pindex)) {
headers.push_back(pindex);
10 years ago
if (headers.size() == (unsigned long)count)
break;
pindex = chainActive.Next(pindex);
}
if (rf == RF_BINARY || rf == RF_HEX) {
try {
for (const CBlockIndex *pindex : headers) {
ssHeader << pindex->GetBlockHeader();
}
} catch (const std::runtime_error&) {
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Failed to read index entry");
}
}
10 years ago
}
switch (rf) {
case RF_BINARY: {
string binaryHeader = ssHeader.str();
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
9 years ago
req->WriteHeader("Content-Type", "application/octet-stream");
req->WriteReply(HTTP_OK, binaryHeader);
10 years ago
return true;
}
case RF_HEX: {
string strHex = HexStr(ssHeader.begin(), ssHeader.end()) + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "text/plain");
req->WriteReply(HTTP_OK, strHex);
10 years ago
return true;
}
case RF_JSON: {
UniValue jsonHeaders(UniValue::VARR);
BOOST_FOREACH(const CBlockIndex *pindex, headers) {
jsonHeaders.push_back(blockheaderToJSON(pindex));
}
string strJSON = jsonHeaders.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
10 years ago
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: .bin, .hex)");
10 years ago
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_block(HTTPRequest* req,
const std::string& strURIPart,
bool showTxDetails)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
string hashStr = params[0];
uint256 hash;
if (!ParseHashStr(hashStr, hash))
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
9 years ago
return RESTERR(req, HTTP_BAD_REQUEST, "Invalid hash: " + hashStr);
CBlock block;
CBlockIndex* pblockindex = NULL;
{
LOCK(cs_main);
if (mapBlockIndex.count(hash) == 0)
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, hashStr + " not found");
pblockindex = mapBlockIndex[hash];
if (fHavePruned && !(pblockindex->nStatus & BLOCK_HAVE_DATA) && pblockindex->nTx > 0)
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, hashStr + " not available (pruned data)");
if (!ReadBlockFromDisk(block, pblockindex,1))
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, hashStr + " not found");
}
CDataStream ssBlock(SER_NETWORK, PROTOCOL_VERSION);
ssBlock << block;
switch (rf) {
case RF_BINARY: {
string binaryBlock = ssBlock.str();
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
9 years ago
req->WriteHeader("Content-Type", "application/octet-stream");
req->WriteReply(HTTP_OK, binaryBlock);
return true;
}
case RF_HEX: {
string strHex = HexStr(ssBlock.begin(), ssBlock.end()) + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "text/plain");
req->WriteReply(HTTP_OK, strHex);
return true;
}
case RF_JSON: {
UniValue objBlock = blockToJSON(block, pblockindex, showTxDetails);
string strJSON = objBlock.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: " + AvailableDataFormatsString() + ")");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_block_extended(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
return rest_block(req, strURIPart, true);
}
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
9 years ago
static bool rest_block_notxdetails(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
return rest_block(req, strURIPart, false);
}
// A bit of a hack - dependency on a function defined in rpc/blockchain.cpp
4 years ago
UniValue getblockchaininfo(const UniValue& params, bool fHelp, const CPubKey& mypk);
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
9 years ago
static bool rest_chaininfo(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
switch (rf) {
case RF_JSON: {
UniValue rpcParams(UniValue::VARR);
4 years ago
UniValue chainInfoObject = getblockchaininfo(rpcParams, false, CPubKey());
string strJSON = chainInfoObject.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: json)");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_mempool_info(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
switch (rf) {
case RF_JSON: {
UniValue mempoolInfoObject = mempoolInfoToJSON();
string strJSON = mempoolInfoObject.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: json)");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_mempool_contents(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
switch (rf) {
case RF_JSON: {
UniValue mempoolObject = mempoolToJSON(true);
string strJSON = mempoolObject.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: json)");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_tx(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
const RetFormat rf = ParseDataFormat(params, strURIPart);
string hashStr = params[0];
uint256 hash;
if (!ParseHashStr(hashStr, hash))
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
9 years ago
return RESTERR(req, HTTP_BAD_REQUEST, "Invalid hash: " + hashStr);
CTransaction tx;
uint256 hashBlock = uint256();
if (!GetTransaction(hash, tx, hashBlock, true))
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, hashStr + " not found");
CDataStream ssTx(SER_NETWORK, PROTOCOL_VERSION);
ssTx << tx;
switch (rf) {
case RF_BINARY: {
string binaryTx = ssTx.str();
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
9 years ago
req->WriteHeader("Content-Type", "application/octet-stream");
req->WriteReply(HTTP_OK, binaryTx);
return true;
}
case RF_HEX: {
string strHex = HexStr(ssTx.begin(), ssTx.end()) + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "text/plain");
req->WriteReply(HTTP_OK, strHex);
return true;
}
case RF_JSON: {
UniValue objTx(UniValue::VOBJ);
TxToJSON(tx, hashBlock, objTx);
string strJSON = objTx.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: " + AvailableDataFormatsString() + ")");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
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
9 years ago
static bool rest_getutxos(HTTPRequest* req, const std::string& strURIPart)
{
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
9 years ago
if (!CheckWarmup(req))
return false;
vector<string> params;
enum RetFormat rf = ParseDataFormat(params, strURIPart);
vector<string> uriParts;
if (params.size() > 0 && params[0].length() > 1)
{
std::string strUriParams = params[0].substr(1);
boost::split(uriParts, strUriParams, boost::is_any_of("/"));
}
Squashed commit of the following: commit 5e7222e4bc0401ef8c6d8049b12a62d4854ac85c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:20:51 2018 +0200 Cleanup commit 2e1bc7a7cd6c72e7c3d2ff74cb30f7a56515006c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:19:53 2018 +0200 Cleanup commit edd7fa87fb2c839c17457ff004d258a049df832f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:18:57 2018 +0200 Cleanup commit ee34e1433806655a7123f0617802aa4771507dff Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:18:10 2018 +0200 Cleanup commit 20779e4021b8ab95a87289d2741ad2f0fbc7fb39 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:16:52 2018 +0200 Cleanup commit 084e1aa563807f5625ad3aaff376b598e139f2a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:42:49 2018 +0200 Fix typo commit c61a7c2319d3b9b96d1b5ad52ecf9d4f2fd92658 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:37:43 2018 +0200 Cleanup commit e435c0229b0cbe3f4a77f43b01ca87ed0552d405 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:17:58 2018 +0200 Fix typos commit e05bff3fea8915e95a473fe3266b2b1f727deca0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:59:32 2018 +0200 Fix typo commit 8c55c7840232cef7fa4389a12f6f220e86f5f581 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:46:33 2018 +0200 Fix typos commit a1edfcc5cc29d815ba7e8c4baaf14c23ef93af64 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:39:41 2018 +0200 Fix typos commit 2ce2c4d180e936ccc5c10745a6430fda5de38a9b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:14:10 2018 +0200 Fix typo commit 5bdc6cd5bc9cff93aa48fbdeda36d4d9774bfa18 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:12:14 2018 +0200 Fix typo commit d08749f549575efc6f44a7f80850bc439c12ad5c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:54:06 2018 +0200 Revert one change commit a734bb1191c692f09f58bcc8e85160ce7c839905 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:52:45 2018 +0200 Fix typo commit 95fbc8d94bbefc0db989c83d0f053111bfed45e7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:51:33 2018 +0200 Fix typos commit d17d540a83d035cf9a200f9a8b19f0fab6084728 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:49:36 2018 +0200 Fix typo commit c4bf4402210bcb926ccfb3928afeb3a8a7490b42 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:48:09 2018 +0200 Fix typo commit 25e7990848a1d723702e2d041c04bc68a6c1275f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:47:01 2018 +0200 Fix typo commit d72ffb5b0253e0d7b992ffe13c40695421378dc3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:45:20 2018 +0200 Fix typo commit 705e6f271192a575cc99d794545b0efe75d964c4 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:41:19 2018 +0200 Revert one change commit 4fd26cd29e21c42b027e37da2616761ebc399d16 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:39:41 2018 +0200 Revert commit commit 8a5cc627b1048368fe8807973d1f542bab2e045f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:28:56 2018 +0200 Fix typo commit 0a24baa7258c0ae0f244d82af8d0831b148ab012 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:15:45 2018 +0200 Fix typo commit 38f93ecd90171fb881243f0de55b3452daccff20 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:56:49 2018 +0200 Fix typos commit 15446fd62400c36c2a51f7e6f13725cc8adfd924 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:48:00 2018 +0200 Fix typos commit 76533b41986bbc5826070a1e644215a74757c1db Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:04:38 2018 +0200 Fix typo commit aea330c2b0bf76975ec69142a732288cc8b192bd Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:46:29 2018 +0200 Fix typo commit 8b1b1d0be1dc44f36c22c54d1a3d56d84d456b92 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:40:23 2018 +0200 Fix typo commit 46ea76785a26cf20a664ed211c8f3fb9a283e127 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:14:17 2018 +0200 Fix typo commit e0d7c5748545dd0975507ad603623072fcc6bdea Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:08:24 2018 +0200 Fix typo commit 604d5a244323b17ba596b12d245407e1cf63a375 Merge: 6c081ca 1c65b2b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:03:23 2018 +0200 Merge pull request #36 from rex4539/patch-36 Fix typo commit 6c081caf28b7cef9e62ed523284dff90e4add16d Merge: 899e5d2 88fa2d9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:02:49 2018 +0200 Merge pull request #35 from rex4539/patch-35 Fix typo commit 899e5d2c343ac7ea5069b8548e5df86c8e963e21 Merge: 6380c7f 40e73e2 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:02:16 2018 +0200 Merge pull request #34 from rex4539/patch-34 Fix typo commit 6380c7f740246474c69d8145bde61688551efe83 Merge: f592274 4567667 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:01:47 2018 +0200 Merge pull request #33 from rex4539/patch-33 Fix typos commit f592274a713162da0083bd6d22fb47cb1afcdba9 Merge: d86ef7e 4aeaa3a Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:01:14 2018 +0200 Merge pull request #32 from rex4539/patch-32 Fix typo commit d86ef7e5e4f7e9c2014358ec5b647d1815eb304d Merge: fe0b432 5cdd1b2 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:00:41 2018 +0200 Merge pull request #31 from rex4539/patch-31 Fix typo commit fe0b432ee125ae0b876af2c26139dfc979005a3b Merge: 6fd6d0d 70130d0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:00:12 2018 +0200 Merge pull request #30 from rex4539/patch-30 Fix typos commit 6fd6d0dcf3714118a623c0d8d84aabb4578410a8 Merge: 389660f 3377426 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:59:42 2018 +0200 Merge pull request #29 from rex4539/patch-29 Fix typo commit 389660f856cb60ff475a8757aad3873b99213cc0 Merge: a0b85ce 40643eb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:59:15 2018 +0200 Merge pull request #28 from rex4539/patch-28 Fix typo commit a0b85ce3b4d2e6596da0727e05c1fe15c289b1e7 Merge: 6f9a1c7 23ead80 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:58:42 2018 +0200 Merge pull request #27 from rex4539/patch-27 Fix typo commit 6f9a1c71a680bb3ed1c249dd42bf0a54663d0af3 Merge: b880547 3612eab Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:58:06 2018 +0200 Merge pull request #26 from rex4539/patch-26 Patch 26 commit b880547415afeae36bd19867388e60a3040a15ca Merge: a3b7da2 5c3177f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:57:24 2018 +0200 Merge pull request #25 from rex4539/patch-25 Fix typo commit a3b7da2c6d6691f38751292e1aea63498a325788 Merge: edd8586 60026ef Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:56:52 2018 +0200 Merge pull request #24 from rex4539/patch-24 Fix typo commit edd8586fdf8c112f4c513804610c237d7e2e80ef Merge: 0c28eb7 f979c00 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:56:12 2018 +0200 Merge pull request #23 from rex4539/patch-23 Fix typo commit 0c28eb7717821b1d68016f40911d07f2a7231b4f Merge: 775beb6 c900722 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:55:42 2018 +0200 Merge pull request #22 from rex4539/patch-22 Fix typo commit 775beb625beb1fc5f72388c076b295de4b8ff039 Merge: a0cf889 1027543 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:55:16 2018 +0200 Merge pull request #21 from rex4539/patch-21 Fix typo commit a0cf88971e756c37c406bab3066c11d6fc7f6d74 Merge: 4504b48 f3fa89b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:54:44 2018 +0200 Merge pull request #20 from rex4539/patch-20 Fix typo commit 4504b4824b3438e931ca8d24a56b1887657e87cd Merge: dd0bcbf 2699eca Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:54:20 2018 +0200 Merge pull request #19 from rex4539/patch-19 Fix typo commit dd0bcbfc89293e9760156d5534f3a558451e1f29 Merge: abfb65a f02ef2e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:53:46 2018 +0200 Merge pull request #18 from rex4539/patch-18 Fix typos commit abfb65afaed49c34b9875df79f6fe6eb2b7bf769 Merge: 68b46b7 6485c90 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:53:08 2018 +0200 Merge pull request #17 from rex4539/patch-17 Fix typo commit 68b46b75d2e5b7ae97e83fc5541c46b4907a7899 Merge: a131e84 fcc0828 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:52:39 2018 +0200 Merge pull request #16 from rex4539/patch-16 Fix typo commit a131e844652e58aff78fa8952e7547a9ba82b8a1 Merge: 8487c0e 8a688ff Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:54 2018 +0200 Merge pull request #15 from rex4539/patch-15 Fix typo commit 8487c0e39092b74e977c7a60f4a07a27606756a8 Merge: bcc4cb4 bb60b83 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:28 2018 +0200 Merge pull request #14 from rex4539/patch-14 Fix typos commit bcc4cb46130e789faa9adae9b159ca818f67ec52 Merge: 23e66e9 53539bb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:00 2018 +0200 Merge pull request #13 from rex4539/patch-13 Fix typos commit 23e66e956bff2d6935c7a4dd570d457294018a77 Merge: 56956cf 0808445 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:50:27 2018 +0200 Merge pull request #12 from rex4539/patch-12 Fix typo commit 56956cf23ba1208aa39cb3ab1ef60375c6630263 Merge: 77007d4 7a4f064 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:49:59 2018 +0200 Merge pull request #11 from rex4539/patch-11 Fix typo commit 77007d49fa1d8cb80aef02bea1dd15e522a47c90 Merge: e78ad0c 48c33fb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:49:16 2018 +0200 Merge pull request #10 from rex4539/patch-10 Fix typo commit e78ad0cf0d91955a848f5e953a042eabdcdac198 Merge: 38a3e08 809f01c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:48:33 2018 +0200 Merge pull request #9 from rex4539/patch-9 Fix typo commit 38a3e08699fe4c4ec715b1783dba18bff6b829fb Merge: eee3c28 fec279c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:48:05 2018 +0200 Merge pull request #8 from rex4539/patch-8 Fix typo commit eee3c286eb84f994310142a9e7fdbd36a671e593 Merge: 702635b cf81b4e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:47:33 2018 +0200 Merge pull request #7 from rex4539/patch-7 Fix typo commit 702635bb34abb2f83ded27ae95deefd5b6e7df93 Merge: d7497ea 3bbcc3d Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:47:01 2018 +0200 Merge pull request #6 from rex4539/patch-6 Fix typo commit d7497ea070e03380cf1d4f533b7dc4b881f724f8 Merge: bfcc1e8 f639727 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:45:33 2018 +0200 Merge pull request #5 from rex4539/patch-5 Fix typos commit bfcc1e8ae2094ca4e9837f623999705f538aff04 Merge: f4440ec 55262fe Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:45:05 2018 +0200 Merge pull request #4 from rex4539/patch-4 Remove space for word "backup" commit f4440ecd4a7367e6bc4a5f75bea112290017ed2b Merge: f8b487f 61d5279 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:44:31 2018 +0200 Merge pull request #3 from rex4539/patch-3 Fix typos in zmq.md commit f8b487f5699990fabc7fc383d02bc728db3cb9aa Merge: 60104a7 f2ce50f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:42:51 2018 +0200 Merge pull request #2 from rex4539/patch-2 Fix typo in security-warnings.md commit 60104a7034f55284afb814e81a1430a8b2b0d8d1 Merge: be262f0 af7dfe0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:41:48 2018 +0200 Merge pull request #1 from rex4539/patch-1 Fix typos commit 1c65b2bd0c49f7f392d0e3a2db14ce1366a87171 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:35:26 2018 +0200 Fix typo commit 88fa2d966a3b462ed34a9a4659fc390711cc0276 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:21:00 2018 +0200 Fix typo commit 40e73e258671f21d2b2205509e9cae1f50294752 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:14:21 2018 +0200 Fix typo commit 4567667fcc8b4197dfd51da34fe82b0f2fb78127 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 06:44:40 2018 +0200 Fix typos commit 4aeaa3a3d6335302c53c0f5f4ef81de05e266479 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:55:25 2018 +0200 Fix typo commit 5cdd1b29b4c90492aa15fed7940984e1d675052f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:36:46 2018 +0200 Fix typo commit 70130d05f1646c8b9fb1f33c4efbe2a5fcf7138b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:28:21 2018 +0200 Fix typos commit 33774261b1c63e5640aa1dd251edb67892ed7a5b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:00:56 2018 +0200 Fix typo commit 40643ebfcd85ee257a4576e85d2fb6c73dad17b5 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:51:57 2018 +0200 Fix typo commit 23ead80e05116ebfeaac0a00d5bd4a158fbeb54e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:29:53 2018 +0200 Fix typo commit 3612eaba2dcf273e94cac9ad889723776ce55108 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:19:36 2018 +0200 Fix typos commit 5c3177f5d191d1f4e4d9f78ae4b75381010f7768 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:13:03 2018 +0200 Fix typo commit 60026efe27a39300e428879ad8dba94f19934870 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:08:09 2018 +0200 Fix typo commit f979c0074efd66804f229c8b3cc6e812d7f26406 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:01:44 2018 +0200 Fix typo commit c9007220a8a727c1cfe3b25b453c178eacd431f3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:52:33 2018 +0200 Fix typo commit 1027543bd30701c4b09aa66226281a10563db910 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:36:19 2018 +0200 Fix typo commit f3fa89bcd30e0cb45ff4391e78d02452c9227be0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:34:37 2018 +0200 Fix typo commit 2699eca938f1e413a29d4408a271aaafd27969cc Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:30:29 2018 +0200 Fix typo commit f02ef2e495fe43142d305f5c4f40dcfa3d2cb423 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:22:36 2018 +0200 Fix typos commit 6485c908433bb91fd70d7e18cf3611c9a96115a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:10:06 2018 +0200 Fix typo commit fcc082850564b14b86b1932dfc5a099816c72ef1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:06:26 2018 +0200 Fix typo commit 8a688ff7405d67bd4c77b0aa0ebdd4b4a8a9a6a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:02:50 2018 +0200 Fix typo commit bb60b83853ed0a82ca47dd58d55f1849ddcf23ab Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 02:59:25 2018 +0200 Fix typos commit 53539bb720c7676b9d37e25dde3423db3aa7bfa1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 02:50:55 2018 +0200 Fix typos commit 080844581d6488ab797ac188acae9c4b2e1d0c59 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 01:05:54 2018 +0200 Fix typo commit 7a4f0649ac5e71f39f0bef7f2e1fcb6fafad0291 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:16:31 2018 +0200 Fix typo commit 48c33fb3f9ab1ad287987d147ee4bbe186f7ade1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:07:42 2018 +0200 Fix typo commit 809f01ca4f785a7b5bc9cc2c388e0ae814ecaa95 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:02:34 2018 +0200 Fix typo commit fec279cac89aa917be929447c81177811728361a Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:55:27 2018 +0200 Fix typo commit cf81b4e12399570545372d4c9daceca8e70142d5 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:48:43 2018 +0200 Fix typo commit 3bbcc3d9986caf8df99bec5d8a18d0f0c8990e06 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:28:52 2018 +0200 Fix typo commit f639727525dbd23f5f2d0f89e7be13d868e984c3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:13:12 2018 +0200 Fix typos commit 55262fe9c5e1e127c6b817a0c2ab3f9db3ac35b9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:46:52 2018 +0200 Remove space for word "backup" commit 61d52797d4d26a90dcc15e2bcd6f19a5f36faac3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:23:31 2018 +0200 Fix typos in zmq.md commit f2ce50f10e67b4265e559a432681bc44828ae59b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:12:58 2018 +0200 Fix typo in security-warnings.md commit af7dfe046c12109e44ddc18dff07ede8755cf4f9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 21:59:24 2018 +0200 Fix typos Signed-off-by: Daira Hopwood <daira@jacaranda.org>
6 years ago
// throw exception in case of an empty request
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
9 years ago
std::string strRequestMutable = req->ReadBody();
if (strRequestMutable.length() == 0 && uriParts.size() == 0)
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Error: empty request");
bool fInputParsed = false;
bool fCheckMemPool = false;
vector<COutPoint> vOutPoints;
// parse/deserialize input
// input-format = output-format, rest/getutxos/bin requires binary input, gives binary output, ...
if (uriParts.size() > 0)
{
//inputs is sent over URI scheme (/rest/getutxos/checkmempool/txid1-n/txid2-n/...)
if (uriParts.size() > 0 && uriParts[0] == "checkmempool")
fCheckMemPool = true;
for (size_t i = (fCheckMemPool) ? 1 : 0; i < uriParts.size(); i++)
{
uint256 txid;
int32_t nOutput;
std::string strTxid = uriParts[i].substr(0, uriParts[i].find("-"));
std::string strOutput = uriParts[i].substr(uriParts[i].find("-")+1);
if (!ParseInt32(strOutput, &nOutput) || !IsHex(strTxid))
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Parse error");
txid.SetHex(strTxid);
vOutPoints.push_back(COutPoint(txid, (uint32_t)nOutput));
}
if (vOutPoints.size() > 0)
fInputParsed = true;
else
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Error: empty request");
}
switch (rf) {
case RF_HEX: {
// convert hex to bin, continue then with bin part
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
9 years ago
std::vector<unsigned char> strRequestV = ParseHex(strRequestMutable);
strRequestMutable.assign(strRequestV.begin(), strRequestV.end());
}
case RF_BINARY: {
try {
//deserialize only if user sent a request
if (strRequestMutable.size() > 0)
{
if (fInputParsed) //don't allow sending input over URI and HTTP RAW DATA
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Combination of URI scheme inputs and raw post data is not allowed");
CDataStream oss(SER_NETWORK, PROTOCOL_VERSION);
oss << strRequestMutable;
oss >> fCheckMemPool;
oss >> vOutPoints;
}
} catch (const std::ios_base::failure& e) {
// abort in case of unreadable binary data
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Parse error");
}
break;
}
case RF_JSON: {
if (!fInputParsed)
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, "Error: empty request");
break;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: " + AvailableDataFormatsString() + ")");
}
}
// limit max outpoints
if (vOutPoints.size() > MAX_GETUTXOS_OUTPOINTS)
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
9 years ago
return RESTERR(req, HTTP_INTERNAL_SERVER_ERROR, strprintf("Error: max outpoints exceeded (max: %d, tried: %d)", MAX_GETUTXOS_OUTPOINTS, vOutPoints.size()));
Squashed commit of the following: commit 5e7222e4bc0401ef8c6d8049b12a62d4854ac85c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:20:51 2018 +0200 Cleanup commit 2e1bc7a7cd6c72e7c3d2ff74cb30f7a56515006c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:19:53 2018 +0200 Cleanup commit edd7fa87fb2c839c17457ff004d258a049df832f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:18:57 2018 +0200 Cleanup commit ee34e1433806655a7123f0617802aa4771507dff Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:18:10 2018 +0200 Cleanup commit 20779e4021b8ab95a87289d2741ad2f0fbc7fb39 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Thu Mar 1 21:16:52 2018 +0200 Cleanup commit 084e1aa563807f5625ad3aaff376b598e139f2a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:42:49 2018 +0200 Fix typo commit c61a7c2319d3b9b96d1b5ad52ecf9d4f2fd92658 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:37:43 2018 +0200 Cleanup commit e435c0229b0cbe3f4a77f43b01ca87ed0552d405 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 18:17:58 2018 +0200 Fix typos commit e05bff3fea8915e95a473fe3266b2b1f727deca0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:59:32 2018 +0200 Fix typo commit 8c55c7840232cef7fa4389a12f6f220e86f5f581 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:46:33 2018 +0200 Fix typos commit a1edfcc5cc29d815ba7e8c4baaf14c23ef93af64 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:39:41 2018 +0200 Fix typos commit 2ce2c4d180e936ccc5c10745a6430fda5de38a9b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:14:10 2018 +0200 Fix typo commit 5bdc6cd5bc9cff93aa48fbdeda36d4d9774bfa18 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 17:12:14 2018 +0200 Fix typo commit d08749f549575efc6f44a7f80850bc439c12ad5c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:54:06 2018 +0200 Revert one change commit a734bb1191c692f09f58bcc8e85160ce7c839905 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:52:45 2018 +0200 Fix typo commit 95fbc8d94bbefc0db989c83d0f053111bfed45e7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:51:33 2018 +0200 Fix typos commit d17d540a83d035cf9a200f9a8b19f0fab6084728 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:49:36 2018 +0200 Fix typo commit c4bf4402210bcb926ccfb3928afeb3a8a7490b42 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:48:09 2018 +0200 Fix typo commit 25e7990848a1d723702e2d041c04bc68a6c1275f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:47:01 2018 +0200 Fix typo commit d72ffb5b0253e0d7b992ffe13c40695421378dc3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:45:20 2018 +0200 Fix typo commit 705e6f271192a575cc99d794545b0efe75d964c4 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:41:19 2018 +0200 Revert one change commit 4fd26cd29e21c42b027e37da2616761ebc399d16 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:39:41 2018 +0200 Revert commit commit 8a5cc627b1048368fe8807973d1f542bab2e045f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:28:56 2018 +0200 Fix typo commit 0a24baa7258c0ae0f244d82af8d0831b148ab012 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 16:15:45 2018 +0200 Fix typo commit 38f93ecd90171fb881243f0de55b3452daccff20 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:56:49 2018 +0200 Fix typos commit 15446fd62400c36c2a51f7e6f13725cc8adfd924 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:48:00 2018 +0200 Fix typos commit 76533b41986bbc5826070a1e644215a74757c1db Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 15:04:38 2018 +0200 Fix typo commit aea330c2b0bf76975ec69142a732288cc8b192bd Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:46:29 2018 +0200 Fix typo commit 8b1b1d0be1dc44f36c22c54d1a3d56d84d456b92 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:40:23 2018 +0200 Fix typo commit 46ea76785a26cf20a664ed211c8f3fb9a283e127 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:14:17 2018 +0200 Fix typo commit e0d7c5748545dd0975507ad603623072fcc6bdea Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 14:08:24 2018 +0200 Fix typo commit 604d5a244323b17ba596b12d245407e1cf63a375 Merge: 6c081ca 1c65b2b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:03:23 2018 +0200 Merge pull request #36 from rex4539/patch-36 Fix typo commit 6c081caf28b7cef9e62ed523284dff90e4add16d Merge: 899e5d2 88fa2d9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:02:49 2018 +0200 Merge pull request #35 from rex4539/patch-35 Fix typo commit 899e5d2c343ac7ea5069b8548e5df86c8e963e21 Merge: 6380c7f 40e73e2 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:02:16 2018 +0200 Merge pull request #34 from rex4539/patch-34 Fix typo commit 6380c7f740246474c69d8145bde61688551efe83 Merge: f592274 4567667 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:01:47 2018 +0200 Merge pull request #33 from rex4539/patch-33 Fix typos commit f592274a713162da0083bd6d22fb47cb1afcdba9 Merge: d86ef7e 4aeaa3a Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:01:14 2018 +0200 Merge pull request #32 from rex4539/patch-32 Fix typo commit d86ef7e5e4f7e9c2014358ec5b647d1815eb304d Merge: fe0b432 5cdd1b2 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:00:41 2018 +0200 Merge pull request #31 from rex4539/patch-31 Fix typo commit fe0b432ee125ae0b876af2c26139dfc979005a3b Merge: 6fd6d0d 70130d0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 09:00:12 2018 +0200 Merge pull request #30 from rex4539/patch-30 Fix typos commit 6fd6d0dcf3714118a623c0d8d84aabb4578410a8 Merge: 389660f 3377426 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:59:42 2018 +0200 Merge pull request #29 from rex4539/patch-29 Fix typo commit 389660f856cb60ff475a8757aad3873b99213cc0 Merge: a0b85ce 40643eb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:59:15 2018 +0200 Merge pull request #28 from rex4539/patch-28 Fix typo commit a0b85ce3b4d2e6596da0727e05c1fe15c289b1e7 Merge: 6f9a1c7 23ead80 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:58:42 2018 +0200 Merge pull request #27 from rex4539/patch-27 Fix typo commit 6f9a1c71a680bb3ed1c249dd42bf0a54663d0af3 Merge: b880547 3612eab Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:58:06 2018 +0200 Merge pull request #26 from rex4539/patch-26 Patch 26 commit b880547415afeae36bd19867388e60a3040a15ca Merge: a3b7da2 5c3177f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:57:24 2018 +0200 Merge pull request #25 from rex4539/patch-25 Fix typo commit a3b7da2c6d6691f38751292e1aea63498a325788 Merge: edd8586 60026ef Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:56:52 2018 +0200 Merge pull request #24 from rex4539/patch-24 Fix typo commit edd8586fdf8c112f4c513804610c237d7e2e80ef Merge: 0c28eb7 f979c00 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:56:12 2018 +0200 Merge pull request #23 from rex4539/patch-23 Fix typo commit 0c28eb7717821b1d68016f40911d07f2a7231b4f Merge: 775beb6 c900722 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:55:42 2018 +0200 Merge pull request #22 from rex4539/patch-22 Fix typo commit 775beb625beb1fc5f72388c076b295de4b8ff039 Merge: a0cf889 1027543 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:55:16 2018 +0200 Merge pull request #21 from rex4539/patch-21 Fix typo commit a0cf88971e756c37c406bab3066c11d6fc7f6d74 Merge: 4504b48 f3fa89b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:54:44 2018 +0200 Merge pull request #20 from rex4539/patch-20 Fix typo commit 4504b4824b3438e931ca8d24a56b1887657e87cd Merge: dd0bcbf 2699eca Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:54:20 2018 +0200 Merge pull request #19 from rex4539/patch-19 Fix typo commit dd0bcbfc89293e9760156d5534f3a558451e1f29 Merge: abfb65a f02ef2e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:53:46 2018 +0200 Merge pull request #18 from rex4539/patch-18 Fix typos commit abfb65afaed49c34b9875df79f6fe6eb2b7bf769 Merge: 68b46b7 6485c90 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:53:08 2018 +0200 Merge pull request #17 from rex4539/patch-17 Fix typo commit 68b46b75d2e5b7ae97e83fc5541c46b4907a7899 Merge: a131e84 fcc0828 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:52:39 2018 +0200 Merge pull request #16 from rex4539/patch-16 Fix typo commit a131e844652e58aff78fa8952e7547a9ba82b8a1 Merge: 8487c0e 8a688ff Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:54 2018 +0200 Merge pull request #15 from rex4539/patch-15 Fix typo commit 8487c0e39092b74e977c7a60f4a07a27606756a8 Merge: bcc4cb4 bb60b83 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:28 2018 +0200 Merge pull request #14 from rex4539/patch-14 Fix typos commit bcc4cb46130e789faa9adae9b159ca818f67ec52 Merge: 23e66e9 53539bb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:51:00 2018 +0200 Merge pull request #13 from rex4539/patch-13 Fix typos commit 23e66e956bff2d6935c7a4dd570d457294018a77 Merge: 56956cf 0808445 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:50:27 2018 +0200 Merge pull request #12 from rex4539/patch-12 Fix typo commit 56956cf23ba1208aa39cb3ab1ef60375c6630263 Merge: 77007d4 7a4f064 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:49:59 2018 +0200 Merge pull request #11 from rex4539/patch-11 Fix typo commit 77007d49fa1d8cb80aef02bea1dd15e522a47c90 Merge: e78ad0c 48c33fb Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:49:16 2018 +0200 Merge pull request #10 from rex4539/patch-10 Fix typo commit e78ad0cf0d91955a848f5e953a042eabdcdac198 Merge: 38a3e08 809f01c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:48:33 2018 +0200 Merge pull request #9 from rex4539/patch-9 Fix typo commit 38a3e08699fe4c4ec715b1783dba18bff6b829fb Merge: eee3c28 fec279c Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:48:05 2018 +0200 Merge pull request #8 from rex4539/patch-8 Fix typo commit eee3c286eb84f994310142a9e7fdbd36a671e593 Merge: 702635b cf81b4e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:47:33 2018 +0200 Merge pull request #7 from rex4539/patch-7 Fix typo commit 702635bb34abb2f83ded27ae95deefd5b6e7df93 Merge: d7497ea 3bbcc3d Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:47:01 2018 +0200 Merge pull request #6 from rex4539/patch-6 Fix typo commit d7497ea070e03380cf1d4f533b7dc4b881f724f8 Merge: bfcc1e8 f639727 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:45:33 2018 +0200 Merge pull request #5 from rex4539/patch-5 Fix typos commit bfcc1e8ae2094ca4e9837f623999705f538aff04 Merge: f4440ec 55262fe Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:45:05 2018 +0200 Merge pull request #4 from rex4539/patch-4 Remove space for word "backup" commit f4440ecd4a7367e6bc4a5f75bea112290017ed2b Merge: f8b487f 61d5279 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:44:31 2018 +0200 Merge pull request #3 from rex4539/patch-3 Fix typos in zmq.md commit f8b487f5699990fabc7fc383d02bc728db3cb9aa Merge: 60104a7 f2ce50f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:42:51 2018 +0200 Merge pull request #2 from rex4539/patch-2 Fix typo in security-warnings.md commit 60104a7034f55284afb814e81a1430a8b2b0d8d1 Merge: be262f0 af7dfe0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 08:41:48 2018 +0200 Merge pull request #1 from rex4539/patch-1 Fix typos commit 1c65b2bd0c49f7f392d0e3a2db14ce1366a87171 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:35:26 2018 +0200 Fix typo commit 88fa2d966a3b462ed34a9a4659fc390711cc0276 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:21:00 2018 +0200 Fix typo commit 40e73e258671f21d2b2205509e9cae1f50294752 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 07:14:21 2018 +0200 Fix typo commit 4567667fcc8b4197dfd51da34fe82b0f2fb78127 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 06:44:40 2018 +0200 Fix typos commit 4aeaa3a3d6335302c53c0f5f4ef81de05e266479 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:55:25 2018 +0200 Fix typo commit 5cdd1b29b4c90492aa15fed7940984e1d675052f Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:36:46 2018 +0200 Fix typo commit 70130d05f1646c8b9fb1f33c4efbe2a5fcf7138b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:28:21 2018 +0200 Fix typos commit 33774261b1c63e5640aa1dd251edb67892ed7a5b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 05:00:56 2018 +0200 Fix typo commit 40643ebfcd85ee257a4576e85d2fb6c73dad17b5 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:51:57 2018 +0200 Fix typo commit 23ead80e05116ebfeaac0a00d5bd4a158fbeb54e Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:29:53 2018 +0200 Fix typo commit 3612eaba2dcf273e94cac9ad889723776ce55108 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:19:36 2018 +0200 Fix typos commit 5c3177f5d191d1f4e4d9f78ae4b75381010f7768 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:13:03 2018 +0200 Fix typo commit 60026efe27a39300e428879ad8dba94f19934870 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:08:09 2018 +0200 Fix typo commit f979c0074efd66804f229c8b3cc6e812d7f26406 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 04:01:44 2018 +0200 Fix typo commit c9007220a8a727c1cfe3b25b453c178eacd431f3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:52:33 2018 +0200 Fix typo commit 1027543bd30701c4b09aa66226281a10563db910 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:36:19 2018 +0200 Fix typo commit f3fa89bcd30e0cb45ff4391e78d02452c9227be0 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:34:37 2018 +0200 Fix typo commit 2699eca938f1e413a29d4408a271aaafd27969cc Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:30:29 2018 +0200 Fix typo commit f02ef2e495fe43142d305f5c4f40dcfa3d2cb423 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:22:36 2018 +0200 Fix typos commit 6485c908433bb91fd70d7e18cf3611c9a96115a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:10:06 2018 +0200 Fix typo commit fcc082850564b14b86b1932dfc5a099816c72ef1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:06:26 2018 +0200 Fix typo commit 8a688ff7405d67bd4c77b0aa0ebdd4b4a8a9a6a7 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 03:02:50 2018 +0200 Fix typo commit bb60b83853ed0a82ca47dd58d55f1849ddcf23ab Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 02:59:25 2018 +0200 Fix typos commit 53539bb720c7676b9d37e25dde3423db3aa7bfa1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 02:50:55 2018 +0200 Fix typos commit 080844581d6488ab797ac188acae9c4b2e1d0c59 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 01:05:54 2018 +0200 Fix typo commit 7a4f0649ac5e71f39f0bef7f2e1fcb6fafad0291 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:16:31 2018 +0200 Fix typo commit 48c33fb3f9ab1ad287987d147ee4bbe186f7ade1 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:07:42 2018 +0200 Fix typo commit 809f01ca4f785a7b5bc9cc2c388e0ae814ecaa95 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Tue Feb 27 00:02:34 2018 +0200 Fix typo commit fec279cac89aa917be929447c81177811728361a Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:55:27 2018 +0200 Fix typo commit cf81b4e12399570545372d4c9daceca8e70142d5 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:48:43 2018 +0200 Fix typo commit 3bbcc3d9986caf8df99bec5d8a18d0f0c8990e06 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:28:52 2018 +0200 Fix typo commit f639727525dbd23f5f2d0f89e7be13d868e984c3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 23:13:12 2018 +0200 Fix typos commit 55262fe9c5e1e127c6b817a0c2ab3f9db3ac35b9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:46:52 2018 +0200 Remove space for word "backup" commit 61d52797d4d26a90dcc15e2bcd6f19a5f36faac3 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:23:31 2018 +0200 Fix typos in zmq.md commit f2ce50f10e67b4265e559a432681bc44828ae59b Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 22:12:58 2018 +0200 Fix typo in security-warnings.md commit af7dfe046c12109e44ddc18dff07ede8755cf4f9 Author: Dimitris Apostolou <dimitris.apostolou@icloud.com> Date: Mon Feb 26 21:59:24 2018 +0200 Fix typos Signed-off-by: Daira Hopwood <daira@jacaranda.org>
6 years ago
// check spentness and form a bitmap (as well as a JSON capable human-readable string representation)
vector<unsigned char> bitmap;
vector<CCoin> outs;
std::string bitmapStringRepresentation;
boost::dynamic_bitset<unsigned char> hits(vOutPoints.size());
{
LOCK2(cs_main, mempool.cs);
CCoinsView viewDummy;
CCoinsViewCache view(&viewDummy);
CCoinsViewCache& viewChain = *pcoinsTip;
CCoinsViewMemPool viewMempool(&viewChain, mempool);
if (fCheckMemPool)
view.SetBackend(viewMempool); // switch cache backend to db+mempool in case user likes to query mempool
for (size_t i = 0; i < vOutPoints.size(); i++) {
CCoins coins;
uint256 hash = vOutPoints[i].hash;
if (view.GetCoins(hash, coins)) {
mempool.pruneSpent(hash, coins);
if (coins.IsAvailable(vOutPoints[i].n)) {
hits[i] = true;
// Safe to index into vout here because IsAvailable checked if it's off the end of the array, or if
// n is valid but points to an already spent output (IsNull).
CCoin coin;
coin.nTxVer = coins.nVersion;
coin.nHeight = coins.nHeight;
coin.out = coins.vout.at(vOutPoints[i].n);
assert(!coin.out.IsNull());
outs.push_back(coin);
}
}
bitmapStringRepresentation.append(hits[i] ? "1" : "0"); // form a binary string representation (human-readable for json output)
}
}
boost::to_block_range(hits, std::back_inserter(bitmap));
switch (rf) {
case RF_BINARY: {
// serialize data
// use exact same output as mentioned in Bip64
CDataStream ssGetUTXOResponse(SER_NETWORK, PROTOCOL_VERSION);
ssGetUTXOResponse << chainActive.Height() << chainActive.LastTip()->GetBlockHash() << bitmap << outs;
string ssGetUTXOResponseString = ssGetUTXOResponse.str();
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
9 years ago
req->WriteHeader("Content-Type", "application/octet-stream");
req->WriteReply(HTTP_OK, ssGetUTXOResponseString);
return true;
}
case RF_HEX: {
CDataStream ssGetUTXOResponse(SER_NETWORK, PROTOCOL_VERSION);
ssGetUTXOResponse << chainActive.Height() << chainActive.LastTip()->GetBlockHash() << bitmap << outs;
string strHex = HexStr(ssGetUTXOResponse.begin(), ssGetUTXOResponse.end()) + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "text/plain");
req->WriteReply(HTTP_OK, strHex);
return true;
}
case RF_JSON: {
UniValue objGetUTXOResponse(UniValue::VOBJ);
// pack in some essentials
// use more or less the same output as mentioned in Bip64
objGetUTXOResponse.push_back(Pair("chainHeight", chainActive.Height()));
objGetUTXOResponse.push_back(Pair("chaintipHash", chainActive.LastTip()->GetBlockHash().GetHex()));
objGetUTXOResponse.push_back(Pair("bitmap", bitmapStringRepresentation));
UniValue utxos(UniValue::VARR);
BOOST_FOREACH (const CCoin& coin, outs) {
UniValue utxo(UniValue::VOBJ);
utxo.push_back(Pair("txvers", (int32_t)coin.nTxVer));
utxo.push_back(Pair("height", (int32_t)coin.nHeight));
utxo.push_back(Pair("value", ValueFromAmount(coin.out.nValue)));
// include the script in a json output
UniValue o(UniValue::VOBJ);
ScriptPubKeyToJSON(coin.out.scriptPubKey, o, true);
utxo.push_back(Pair("scriptPubKey", o));
utxos.push_back(utxo);
}
objGetUTXOResponse.push_back(Pair("utxos", utxos));
// return json string
string strJSON = objGetUTXOResponse.write() + "\n";
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
9 years ago
req->WriteHeader("Content-Type", "application/json");
req->WriteReply(HTTP_OK, strJSON);
return true;
}
default: {
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
9 years ago
return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: " + AvailableDataFormatsString() + ")");
}
}
// not reached
return true; // continue to process further HTTP reqs on this cxn
}
static const struct {
const char* prefix;
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
9 years ago
bool (*handler)(HTTPRequest* req, const std::string& strReq);
} uri_prefixes[] = {
{"/rest/tx/", rest_tx},
{"/rest/block/notxdetails/", rest_block_notxdetails},
{"/rest/block/", rest_block_extended},
{"/rest/chaininfo", rest_chaininfo},
{"/rest/mempool/info", rest_mempool_info},
{"/rest/mempool/contents", rest_mempool_contents},
10 years ago
{"/rest/headers/", rest_headers},
{"/rest/getutxos", rest_getutxos},
};
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
9 years ago
bool StartREST()
{
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
9 years ago
for (unsigned int i = 0; i < ARRAYLEN(uri_prefixes); i++)
RegisterHTTPHandler(uri_prefixes[i].prefix, false, uri_prefixes[i].handler);
return true;
}
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
9 years ago
void InterruptREST()
{
}
void StopREST()
{
for (unsigned int i = 0; i < ARRAYLEN(uri_prefixes); i++)
UnregisterHTTPHandler(uri_prefixes[i].prefix, false);
}