@arteymix arteymix released this Jul 25, 2015 · 742 commits to master since this release

Assets 4

This release bring support for two protocols (CGI and SCGI), the routing stack and multiple improvements.

You can verify the release against this SHA1 checksum: d68697070944b725f31aa4537b90f4099e8c9f0c


  • support for CGI and SCGI protocols in VSGI
  • minor code renames and refactor
  • routing stack instead of state
  • Router.invoke to invoke a NextCallback in the Router context
  • then in Route to sequence handling callbacks
  • Docker build based on ubuntu-debootstrap:latest
  • improved user documentation
  • RPM packaging (should be effective for the stable release)


The CGI implementation became a base implementation for FastCGI and SCGI to reuse the CGI/1.1 specification as these two protocols are its derivatives.


The SCGI implementation is simply written out of GIO ThreadedSocketService . It's the best implementation available right now as it has full non-blocking I/O support.

Routing stack

This is probably the biggest change of the release. The alpha introduced the possibility of passing a state to the next handler, but that was a poor design decision due to multiple limitations. This release introduces a routing stack where matchers and handlers are allowed to push and pop from.

The new design has many advantages:

  • use the stack to push request parameters (Request.params is deprecated)
  • pop value from multiple preceding handlers (no data is lost)

The Request.params will be removed for the final release as it does not have its place in VSGI.

Contextual invocation

The contextual invocation solve the situations where the routing context is lost like in asynchronous callback and some exception handling provided by the Router can become handy.

The initial handling is performed using invoke to reuse the handling code and provide consistent behavior.

app.get ("", (req, res) => {
    res.body.write_async ("Hello world!".data, Priority.DEFAULT, null, () => {
        app.invoke (req, res, () => {
            throw new ClientError.CREATED ("/task/2");

Handling sequence

then has been added to Route to create handling sequence, which are an elegant way of describing a set of handling callbacks sharing a common matcher. It combines really well with handling middlewares to perform operations like authentication prior to process the request further.

As this is only routing sugar, next still have to be called to pass to the next handler in the sequence.

app.get ("", authenticate).then((req, res, next) => {
    // authenticated...
    next ();
}).then((req, res) => {
   // last step...