Unable to make "keep-alive" connections for CallRPC or RPCAcceptHandler #5262

In ReadHTTPStatus, there exists an implementation of reading protocol version, but never expose to nProto, either in rpcserver.cpp or in bitcoin-cli.cpp. The nProto is by default set to zero, which caused the ReadHTTPMessage to close the connection on each call.

We really need a RPC testcase in qa/rpc-tests for this. As long as there is no regression test case, an obscure feature like this is bound to stop working.

Indeed the keep-alive implementation is not working but partial available in the code. I try to write some http keep-alive rpc-tests and finish/fix the implementation.

I checked the whole http handling. The RPC server does correctly handles persistent connection (according to http 1.1). The RPC server can handle multiple requests/responses within the same http connection. I wrote a rcp-test for this, but it's probably not worth committing to the core. @zenixls2 I cannot follow your reported issue. I saw that the bitcoin-cli utility is not able to process multiple http requests/responses in the same http-connection. But obviously this also not necessary for the bitcoin-cli app itself (one app-run executes one rpc call). As a http-client there is no need in bitcoin-core to support a persistent (keep-alive) connection. It would need some effort to make the internals (Object CallRPC(const string& strMethod, const Array& params) http-persistent-keep-alive-conform. IMO there is no need for this, but feel free to contribute this in a PR.

IMO: issue can be close.

@jonasschnelli There was at least one bug in the past related to keep-alive in the HTTP server. I think it would be worth it to commit the test, as long as you have written it.

here we go: #5436

I wonder if we ought to be disabling keep-alive support as long as idle connections prevent new ones from working (by tying up a RPC thread)?

The magic keyword for that would be "timeout". Apaches default timeout is 15s. That would also be feasible for bitcoind. I never checked the timeout behavior.

Disabling keep-alive could harm heavy rpc and REST user. Because it gives the possible to do more queries with less resources.

Zombi-Ideling connections are only there becaus of wrong client implementation. A client needs to close the connection at the end. We don't have the unknown browser situation so we should expect the rpc clients work as expected and close connections at the end.

Thanks for testing @jonasschnelli ! Closing this.

I don't agree with disabling keep-alive by default. It's up to the user (and those delegated to w/ -rpcallow) to use the RPC server responsibly, if he wants to run a slowloris attack against it to hold up threads, so be it.