Feature request: ability to check if the connection is still alive

[ngxson]

Following up #1956, I would like to discuss more about the ability to add a method to check if the socket is still alive. This can be useful to cancel the underlay processing for a request, as described in this issue: ggml-org/llama.cpp#9273

Currently, one way to do is to use set_chunked_content_provider, but the problem is that we cannot change the HTTP status code once we're already inside the callback function.

Therefore, I propose 2 solutions here:

My first suggestion is to add something like set_async_response, which works like set_chunked_content_provider but send out the whole response, instead of only the body.

Second suggestion is to add is_alive() to the Handler:

• Server::routing already has Stream &strm in its scope, so we can pass it to Server::dispatch_request
• Then, we can expose it inside Handler, by wrapping it inside a function is_alive(). I'm not sure how it should look like, but that's the idea

Happy do discuss more to see what's the best way to implement this. Thank you!

[yhirose]

@ngxson thanks for the report.

Regarding the first option (set_async_response), I don't know what the interface should look like, and don't know how we can implement it safely and effectively.

As for the second option, it could be possible to pass on the stream object down to a request handler. But we are not able to change Handler since the interface change will end up breaking existing user's code. So the only thing we could do is to add the new method under the '// private members...' on Response object as the PR from @ochafik. However, the PR is pretty dagarous code as I explained in this comment.

Could you show me an example code which shows how the client code checks if the socket is alive? The usage example may help me come up with better ideas. Thanks!

[ngxson]

Yup sure, a minimal example could be:

svr.Get("/task", [&](const Request& req, Response& res) {
  const char * result = nullptr;
  task.run();
  while (result == nullptr) { // wait loop
    sleep(1);
    result = task.get_result();
  }
  res.set_content(result, "text/plain");
});

If I'm in the JS world (i.e. using express library, sorry for strange comparison), I can add a check for req.connection.closed inside the wait loop, it looks like this:

  while (result == nullptr) { // wait loop
    sleep(1);
    if (req.connection.closed) {
      task.cancel();
      return;
    }
    result = task.get_result();
  }

Because everything still happen in the scope of Handler, we're safe here.

---

I looked again at the implementation of @ochafik . The main difference of his approach compared to mine is that he wants to check the state of connection from outside of handler thread:

svr.Get("/task", [&](const Request& req, Response& res) {
  // delegate the check to `task` thread
  task.run([&req]() -> bool { return req.connection.closed; });
  res.set_content(task.get_result(), "text/plain");
});

Indeed, I would also not recommend doing this because it can be difficult to keep track the life cycle of req or res object as you pointed out.

Therefore, I'm proposing here that whatever check must be strictly done in the scope of Handler.

Not sure if this is clear enough, but feel free to discuss more. Thank you!

[yhirose]

@ngxson thanks for helping me to understand your use case clearly!

I have added is_connection_closed method to Request in this pull request.
Do you think if it can work for you? If it's missing something, please let me know.

[yhirose]

The latest version 0.18.5 includes this change.
https://github.com/yhirose/cpp-httplib/releases/tag/v0.18.5