Non-blocking HTTP handler

[zaphoyd]

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.

[zaphoyd]

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);

[zaphoyd]

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.