v0.2.5

The release can be verified against the following SHA-1 checksum:

9c0f35e158f22a1d1eaf4df7eeb8e07af5cea4bc

Changeset

• distribute CTPL and FastCGI bindings
• change the 404 error message to simply include the path and query
• don't set the Content-Type: text/html header as default

From now on, the master trunk will be used for the 0.3 series.

v0.2.4

The release can be checked against the following SHA-1 checksum:

cc0e1893bdcc38edecc54773e92e6c4af4798753

Changeset

• distribute the framework and VSGI as two distrincts shared libraries
• improve many aspects of the SCGI implementation
• fix the URI scheme extraction for CGI and related protocols
• flattening functions for UTF-8 request body

Valum is now distributed as two distincts shared libraries:

• libvsgi which provide all the interfaces and implementations
• libvalum which provide the framework

The change is not visible if you are building with pkg-config; the dependencies are correctly described.

Eventually, the VSGI implementations will decoupled and loaded as dynamic modules, which should provide a nice extensibility and open the gates for custom implementations.

The new flatten_utf8 and flatten_utf8_async complement the previously introduced flattening functions by converting directly the request body into a unicode string. For other encodings, it is better to apply a GLib.CharsetConverter on the input stream.

app.post ("", (req, res) => {
    var data = Soup.Form.decode (req.flatten_utf8 ());
});

app.post ("some-french-endpoint", (req, res, next) => {
    next (req, new ConvertedResponse (res, new CharsetConverted ("utf-8", "iso8859-1")));
}).then ((req, res) => {
    var data = Soup.Form.decode (req.flatten_utf8 ());
});

The code handling non-standard CGI/1.1 headers has been moved in VSGI.CGI.Request so that it can be consistent with real-world usage of the protocol.

The URI scheme has been fixed in VSGI.CGI, it was not extracted and causing a warning. It is inferred from the HTTPS environment variable and fallbacks on PATH_TRANSLATED. Otherwise, it considers that the request is performed with HTTP.

Many improvements has been introduced for SCGI:

• buffer the netstring to avoid many blocking operations
• graceful shutdown for the GLib.SocketService
• option to listen to any open TCP port with the --any flag

v0.2.3

The release can be verified against the following SHA-1 checksum:

cde2bc15b603bf3123a4c0cb1a2373428b63948d

Changeset

• flattening function has been included in this release
• request body has been fixed for the SCGI implementation
• CGI in general has been improved: fixed assertions and Status written first
• use the new TLS certificate API for glib-2.0 (>=2.38) for the libsoup-2.4 implementation
• write_head and write_head_async indicate the number of bytes written

v0.2.2

You can verify the release against the following SHA-1 checksum:

04cdafc28ec89b3d364ec27e95fadf812f429e16

This release bring a couple of fixes:

• Route.then preserve the matching stack
• GLib.Error are handled as 500 code
• better error handling for FastCGI

v0.2.1

The release can be verified against the following SHA-1 checksum:

2a15e84cfa556fd7855f3c695caf99e6787d4ed1

The APIs are preserved with multiple improvements:

• implementations purely rely on a single-thread model
• better error handling: HandlerCallback and NextCallback propagate GLib.Error
• fix SCGI --port flag
• Route.from_rule reuses Route.from_regex
• fix capture extraction with Route.from_regex

v0.2.0

This is the first stable release of Valum and we are proud to announce that we have finally reached API stability. All subsequent releases will strictly follow semantic versioning.

You can verify the release against the following SHA1 checksum:

2fc3424edf560f65c52e86f51e07dcd45ad9e05e

Changeset

• new lookup, sign and verify functions for cookies
• move cookies-related utilities back in VSGI
• set charset to UTF-8 in the default Content-Type header
• write the error message in the response body if it's not used for a specific header
• fix warnings for SCGI and handle IOError properly
• fix owned references on callbacks
• methods and all return the created Route objects
• basic filters for Request and Response
• next pass the Request and Response object for the next handler
• documentation update and improvement
• standalone examples for JSON, Lua, and Memcached

The sources have been restructured to follow GLib conventions and look much cleaner.

The cookies-related utilities have their place in VSGI as they provide compatible features that were usually found in libsoup-2.4, but not compatible with the Request and Response objects.

It is now possible to sign and verify cookies using HMAC signatures.

var signature = Cookies.sign (cookie, ChecksumType.SHA512, "secret".data);

It can later be verified and extracted with VSGI.Cookies.verify:

if (Cookies.verify (cookie, ChecksumType.SHA512, "secret".data, out @value) {
    // cookie is verified and the value is extracted in @value
}

Code, documentation and examples have been updated to use write_all instead of write, which will write until an error occur instead of writing as much as possible.

Instances of VSGI.Server will now require an application identifier used for DBus registration. This breaking change is required as it will make many things possible:

• monitoring
• worker discovery
• GSettings integration

The identifier is the first argument of Server:

new Server ("org.valum.App", (req, res) => {
    res.body.write_all ("Hello world!".data, null);
});

Filters

A filter is a decorator pattern used to modify the regular behavior of Request and Response objects. They can be used to perform various transformations such as stream compression, stream redirection, buffering and immutability.

FilteredRequest and FilteredResponse provide basis to build pretty much any possible filters. It is planned to provide a good set of filters in a future minor release (see issue #117 for more details).

The NextCallback has been redesigned to pass the filtered Request and Response objects in order to integrate nicely with the available filters.

app.get ("", (req, res) => {
    next (req, new BufferedResponse (res, 1024));
}).then ((req, res) => {
    res.body.write_all ("Hello world!".data, null);
});

v0.2.0-beta

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

Changeset

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

CGI

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.

SCGI

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

v0.2.0-alpha

This release brings a new asynchronous API for processing Request and Response objects based on a RAII pattern and taking advantage of automated reference counting from the Vala compiler.

This series mark the stabilization of APIs and any subsequent releases will be subjected to rigorous semantic versionning.

You can verify the release against the following SHA-1 checksum: 570f6711921bb31f0b2284f5baf5a76b31608e96

Changeset

• resources required to process a client request follows the lifecycle of a Connection object that inherits from IOStream
• VSGI.Application have been replaced by a delegate to simplify how an application can be defined
• libsoup-2.4 implementation uses the connection with steal_connection to provide authentic stream operations and a better throughput
• waf 1.8.11 brings fixes for the --thread option which will be useful for future VSGI implementations
• write_head and write_head_async to write the head of the response
• considerably improves the documentation
• head_written property in Response
• better fault tolerance with more error handling
• VSGI implementations are easier to stub and test

General

The changes ensure that the connection is kept alive as long as it is being referenced and since the Request holds such a reference and that the Response holds a Request reference, holding any of these two instances is sufficient to perform stream operations.

Typically, the resources would be freed when returning the control to the server, but this approach does not work with asynchronous operations as they will execute later on.

The first attempt was to introduce a end signal to explicitly notify the server that the resources could be freed, but it was unreliable and really not taking advantage of the automated memory management provided by Vala.

new Server ((req, res, end) => {
    end (); // end must be invoked
});

Now, we simply wrap all the resources within an object following the RAII programming pattern. Resources are freed when both Request and Response are disposed.

new Server ((req, res) => {
    // now,req and res will be freed and thus the connection
});

Writting the head of the response

Two new functions allows one to write the head of the response either synchronously or asynchronously. This is done automatically if the body property is accessed for the first time in Response.

Now, an application must invoke write_head or write_head_async at least once during its processing, unless what an empty message will be produced.

app.get ("", (req, res) => {
    res.status = 404;
    res.write_head ();
});

More testable VSGI implementations

VSGI implementations have been made more testable by exposing easily mockable constructor arguments like IOStream and HashTable.

Consequently, the code coverage has greatly improved to reach 65.59% and it will continuously improve over time.

v0.1.4-alpha

This release brings a couple of fixes and minor features.

You can verify the release against the following SHA-1 checksum: 74b6a9f68a4d8d591beb8786421fc41df5332310

This is the last release of the 0.1 serie.

Changeset

• options for VSGI.Soup
• removes the teardown signal
• moves cookies to Valum to keep VSGI minimal
• uses OptionArg.FILENAME for the FastCGI socket path

Options for VSGI.Soup implementation

Almost all Soup.Server options have been exposed through CLI arguments to conveniently configure the HTTP server runtime. It is not possible to enable HTTPS, listen on a file descriptor or set the Server header.

No more teardown signal!

The teardown signal has been removed since it can be better implemented with a signal handler and next continuation.

v0.1.3-alpha

This release brings a couple of bugfixes, support for more status codes and the possibility to pass state in the next continuation.

More tests have been written and the coverage has reached 58.42%.

The release can be verified against this SHA-1 checksum: 60ea76b69569eab0e4670dbdaa3e70ca32f2db45

Changeset

• fix the null rule to match the empty path
• informational and success status codes
• pass a state in the next continuation
• use the state to pass the error message for status handlers

Informational and success status codes

It is now possible to throw Informational and Success status codes from these two error domains. They can be used to perform automated handling for created resources (201) or protocol switch (101).

Valum will try to support every standardized status codes, so if anything seems to be missing, open an issue or submit a pull request with the required changes.

State in the next continuation

Data can be passed when invoking the next continuation:

app.all (null, (req, res, next) => {
    next ("message for the next handler");
});

app.get ("", (req, res, next, state) => {
    string message = state; // implicit conversion, state is a Value?
});

This approach is used to pass the error message to a status handler and can be generally used to pass the result of a computation to the next handler.