-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-blocking HTTP handler #425
Comments
This allows processing of long running http handlers to defer their response until it is ready without blocking the network thread.
I've pushed a preliminary update that allows deferring the sending of HTTP responses until sometime later. This allows an HTTP handler to yield control back to the main network thread so that it isn't blocked while the response to the HTTP request is being generated. The response can be filled in as data comes in and then can be sent from any thread. Note: This solution still requires buffering the full response. I will be looking into more sophisticated methods of doing this that might allow streaming of responses. Usage: // HTTP Handler
void on_http(websocketpp::connection_hdl hdl) {
endpoint::connection_ptr con = s->get_con_from_hdl(hdl);
con->defer_http_response();
}
// ...
// Later set up the response. Use any of the normal methods you would
// use in the http handler including setting headers, body, status, etc
con->set_body("Hello World!");
con->set_status(websocketpp::http::status_code::ok);
// Finally signal that the response should be written
con->send_http_response();
// or alternatively
// endpoint.send_http_response(hdl); |
The 0.6.0 release contains a non-blocking HTTP handler. More documentation: http://www.zaphoyd.com/websocketpp/manual/reference/handler-list/httphandler A new issue is going to be spun off to deal with the concept of a streaming HTTP handler. |
Right now the http handler is a blocking handler. The entire HTTP response must be generated, buffered, and returned inline in the network thread. While this is happening, the network thread is blocked. This severely limits certain types of long running operations (like database connections and disk I/O) from being used to serve HTTP connections.
A non-blocking HTTP handler would allow more sophisticated HTTP handling in WebSocket++ applications. This is a prerequisite for reverse proxy functionality #266.
The text was updated successfully, but these errors were encountered: