VSGI

VSGI is a middleware that interfaces different web server technologies under a common and simple set of abstractions.

For the moment, it is developed along with Valum to target the needs of a web framework, but it will eventually be extracted and distributed as a shared library.

• HTTP authentication
  • Basic
• Connection
• Request
  • Method
  • Headers
    • Cookies
  • Query
  • Body
    • Flatten
    • Form
    • Multipart body
• Response
  • Status
  • Reason phrase
  • Headers
  • Body
    • Expand
    • Filtering
    • Conversion
  • Tee
  • End
• Cookies
  • Extract cookies
  • Lookup a cookie
  • Marshall a cookie
  • Sign and verify
• Converters
• Server
  • HTTP
    • Options
      • Notes
  • CGI
    • lighttpd
  • FastCGI
    • Options
    • lighttpd
    • Apache
    • Nginx
  • SCGI
    • Options
  • General
  • Load an implementation
  • DBus connection
  • Options
  • Forking
  • Listen on distinct interfaces

VSGI produces process-based applications that are able to communicate with various HTTP servers using standardized protocols.

Entry point

The entry point of a VSGI application is type-compatible with the ApplicationCallback delegate. It is a function of two arguments: a Request and a Response that return a boolean indicating if the request has been or will be processed.

using VSGI;

Server.new_with_application ("http", "org.vsgi.App", (req, res) => {
    // process the request and produce the response...
    return true;
}).run ();

If an application indicate that the request has not been processed, it’s up to the server implementation to decide what will happen.

Error handling

New in version 0.3.

At any moment, an error can be raised and handled by the server implementation which will in turn teardown the connection appropriately.

Server.new_with_application ("http", "org.vsgi.App", (req, res) => {
    throw new IOError.FAILED ("some I/O failed");
});

Asynchronous processing

The asynchronous processing model follows the RAII pattern and wraps all resources in a connection that inherits from GLib.IOStream. It is therefore important that the said connection is kept alive as long as the streams are being used.

The Request holds a reference to the said connection and the Response indirectly does as it holds a reference to the request. Generally speaking, holding a reference on any of these two instances is sufficient to keep the streams usable.

Warning

As VSGI relies on reference counting to free the resources underlying a request, you must keep a reference to either the Request or Response during the processing, including in asynchronous callbacks.

It is important that the connection persist until all streams operations are done as the following example demonstrates:

res.body.write_async.begin ("Hello world!",
                            Priority.DEFAULT,
                            null,
                            (body, result) => {
    // the response reference will make the connection persist
    var written = res.body.write_async.end (result);
});