Hello all,

Recently I've been porting the evhttp server from libevent to the SCGI (Simple Common Gateway Interface) protocol. I got it to respond to test requests correctly for the first time today, so I've uploaded it to Gitorious: https://gitorious.org/libevscgi

The API is mostly the same as evhttp. The biggest difference is that it only implements the server side of the protocol. Another difference is that it only supports Unix domain sockets (though I'll probably add support for TCP sockets later). Also, it uses a few parts of evhttp itself, such as the URI-manipulation functions, the functions for manipulating the TAILQ header-lists, and the response-code symbolic names.

Here is a simple example, taken from the evhttp example https://gist.github.com/793194 with a few minor changes, that demonstrates how to handle SCGI requests in your program:

  #include <event.h>
  #include <event2/http.h> /* Currently only used for response status code 
constants. */
  #include <evscgi/evscgi.h>

  void process_request(struct evscgi_request *req, void *arg)
    struct evbuffer *buf = evbuffer_new();
    if (buf == NULL) return;
    evbuffer_add_printf(buf, "Hello world.\n");
    evscgi_send_reply(req, HTTP_OK, "OK", buf);

  int main(int argc, char **argv)
    struct event_base *base = NULL;
    struct evscgi *scgi = NULL;
    base = event_base_new();
    if (base == NULL) return -1;
    scgi = evscgi_new(base);
    if (scgi == NULL) return -1;
    if (evscgi_bind_unix_socket(scgi, "./scgi_socket") != 0) return -1;
    evscgi_set_gencb(scgi, process_request, NULL);

I don't necessarily mean to keep the API as close as possible to evhttp, however. In particular, I'm thinking of making it possible for an application to receive a request body as a series of chunks (to avoid keeping the whole thing in memory at once), or similarly to receive the headers in a one-at-a-time manner. I didn't know about libevhtp when I started this project, but I might change libevscgi's API to be more like it.

Also, it seems like it would be good to have a protocol-independent API for web applications, similar to Python's WSGI, but using a purely event-driven design. [1] This could be made as a pair of interface classes, one of which represents a request handler (with a method that's called once for each request, and/or several methods for receiving the request a piece at a time) and is implemented by the application, and the other of which represents a server (with methods for registering the application's request handlers with the server instance) and is implemented by wrapper libraries for the different server backends (such as libevhtp, evhttp, libevscgi, and possibly others). (Maybe there should also be another pair of interface classes, one of which represents an active connection and is implemented by the library, the other of which represents an in-progress request and is implemented by the application.) I'm thinking of developing an API like this using either C++ or Vala.

[1] WSGI is not really designed for use in a single-threaded event-driven environment. It provides the request body to the handler as an "input stream" object which the handler blocking-reads from; also, the handler itself provides the response body to the middleware either by returning all of it at once or else "yield"-ing it a piece at a time, in response to one or more pull-requests from the middleware. This design basically forces the middleware to have one process/thread per request, or else handle the requests in a purely serial manner.

Libevent-users mailing list

Reply via email to