Jack middleware performs pre or post processing on requests and responses, such as logging, authentication, etc. Most Jack middleware, by convention, is a function that takes in one argument, “app” (a Jack application, possibly wrapped in other middleware) and returns another Jack application (i.e. another function that takes in an “env” argument and returns a three element array). The returned Jack application will typically optionally do some preprocessing on the request, followed by calling the “app” that was provided, optionally followed by some post processing.

For example, the “Head” middleware calls the original “app”, then checks to see if the request HTTP method was “HEAD”. If so, it clears the body of response before returning it, since HEAD requests shouldn’t have a response body:

function Head(app) {
    return function(env) {
        var result = app(env);
        if (env["REQUEST_METHOD"] === "HEAD")
            result.body = [];
        return result;
    }
}

This style of middleware makes use of a closure to store a reference to the original app.

A more complicated middleware might need to perform post-processing on the body contents. A common pattern is to call the app, then store the body as a property of a “context” and return the context itself in place of the body. The context defines a “forEach” method on the context, which proxies to the stored body property.

It is important to proxy the response body rather than buffer the entire response when dealing with streaming applications, otherwise the middleware will prevent the app from streaming. A good example of this pattern is the CommonLogger middleware, which does this in order to calculate the body length for logging.

A JSGI application is simply a JavaScript function. It takes a single environment argument, and it should return an array containing three elements: the status code (an integer), the headers values (a hash), and a body object (anything that responds to the “forEach” method which yields objects that have a “toByteString()” method).

Narwhal has extended JavaScript String, ByteArray, and ByteString respond to “toByteString” (so they are valid “body” responses), thus the following is a valid JSGI application:

function(env) {
    return {
        status : 200,
        headers : {"Content-Type":"text/plain"},
        body : ["Hello world!"]
    };
}

If you need something more complex with extra state, you can provide a “constructor” in the form of a function:

MyApp = function(something) {
    return function(env) {
        return {
          status : 200,
          headers : {"Content-Type":"text/plain"},
          body : ["Hello " + this.something + "!"]
        };
    }
}

app = MyApp("Fred");

Be careful to ensure your application and middleware is thread-safe if you plan to use a multithreaded server like Jetty and Simple.

The first (and only) argument to the application method is the “environment” object, which contains a number of properties. Many of the standard CGI environment variables are included, as well as some JSGI specific properties which are prefixed with “jsgi.”.

The Request and Response objects are part of Jack, not the JSGI specification, but may be helpful in parsing request parameters, and building a valid response. They are used as follows:

var req = new Jack.Request(env);
var name = req.GET("name");

var resp = new Jack.Response();
resp.setHeader("Content-Type", "text/plain");
resp.write("hello ");
resp.write(name);
resp.write("!");
return resp.finish();

This is roughly equivalent to returning { status : 200, headers : {"Content-Type" : "text/plain"}, body : ["hello "+name+"!"] }

jsgi specification, v0.2

applications

A JSGI application is a JavaScript function. It takes exactly one argument, the environment, and returns a JavaScript Object containing three properties: the status, the headers, and the body.

middleware

JSGI middleware is typically a function that takes at least one other JSGI application and returns another function which is also a JSGI application.

the environment

The environment must be a JavaScript Object instance that includes CGI-like headers. The application is free to modify the environment. The environment is required to include these variables (adopted from PEP333 and Rack), except when they’d be empty, but see below.

• REQUEST_METHOD: The HTTP request method, such as “GET” or “POST”. This cannot ever be an empty string, and so is always required.
• SCRIPT_NAME: The initial portion of the request URL‘s “path” that corresponds to the application object, so that the application knows its virtual “location”. This may be an empty string, if the application corresponds to the “root” of the server.
• PATH_INFO: The remainder of the request URL‘s “path”, designating the virtual “location” of the request‘s target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash. This value may be percent-encoded when I originating from a URL.
• QUERY_STRING: The portion of the request URL that follows the ?, if any. May be empty, but is always required!
• SERVER_NAME, SERVER_PORT: When combined with SCRIPT_NAME and PATH_INFO, these variables can be used to complete the URL. Note, however, that HTTP_HOST, if present, should be used in preference to SERVER_NAME for reconstructing the request URL. SERVER_NAME and SERVER_PORT can never be empty strings, and so are always required.
• HTTP_ Variables: Variables corresponding to the client-supplied HTTP request headers (i.e., variables whose names begin with HTTP_). The presence or absence of these variables should correspond with the presence or absence of the appropriate HTTP header in the request.

In addition to this, the JSGI environment must include these JSGI-specific variables:

• jsgi.version: The Array [0,2], representing this version of JSGI.
• jsgi.url_scheme: http or https, depending on the request URL.
• jsgi.input: See below, the input stream.
• jsgi.errors: See below, the error stream.
• jsgi.multithread: true if the application object may be simultaneously invoked by another thread in the same process, false otherwise.
• jsgi.multiprocess: true if an equivalent application object may be simultaneously invoked by another process, false otherwise.
• jsgi.run_once: true if the server expects (but does not guarantee!) that the application will only be invoked this one time during the life of its containing process. Normally, this will only be true for a server based on CGI (or something similar).

The server or the application can store their own data in the environment, too. The keys must contain at least one dot, and should be prefixed uniquely. The prefix jsgi. is reserved for use with the JSGI core distribution and must not be used otherwise. The environment must not contain the keys HTTP_CONTENT_TYPE or HTTP_CONTENT_LENGTH (use the versions without HTTP). The CGI keys (named without a period) must have String values. There are the following restrictions:

• jsgi.version must be an array of Integers.
• jsgi.url_scheme must either be http or https.
• There must be a valid input stream in jsgi.input.
• There must be a valid error stream in jsgi.errors.
• The REQUEST_METHOD must be a valid token.
• The SCRIPT_NAME, if non-empty, must start with /
• The PATH_INFO, if non-empty, must start with /
• The CONTENT_LENGTH, if given, must consist of digits only.
• One of SCRIPT_NAME or PATH_INFO must be set. PATH_INFO should be / if SCRIPT_NAME is empty. SCRIPT_NAME never should be /, but instead be empty.

the input stream

Must be an input stream.

the error stream

Must be an output stream.

the response

the status

The status, if parsed as integer, must be greater than or equal to 100.

the headers

The header must be a JavaScript object containing key/value pairs of Strings. The header must not contain a Status key, contain keys with : or newlines in their name, contain keys names that end in – or _, but only contain keys that consist of letters, digits, _ or – and start with a letter. The values of the header must be Strings, consisting of lines (for multiple header values) separated by “\n”. The lines must not contain characters below 037.

the content-type

There must be a Content-Type, except when the Status is 1xx, 204 or 304, in which case there must be none given.

the content-length

There must not be a Content-Length header when the Status is 1xx, 204 or 304.

the body

The Body must respond to forEach and must only yield objects which have a toByteString method (including Strings and Binary objects). If the Body responds to close, it will be called after iteration. The Body commonly is an array of Strings or ByteStrings.

acknowledgements

This specification is adapted from the Rack specification (http://rack.rubyforge.org/doc/files/SPEC.html) written by Christian Neukirchen.

Some parts of this specification are adopted from PEP333: Python Web Server Gateway Interface v1.0 (www.python.org/dev/peps/pep-0333/).

The following components essentially match those in Rack.

handlers

• Servlet: complete, for use with Jetty on Rhino, or other servlet container such as Google AppEngine for Java.
• Jetty: complete, simple wrapper for Jetty using Servlet handler (http://www.mortbay.org/jetty/)
• Simple: complete, for use with the Simple webserver (http://www.simpleframework.org/)
• K7: incomplete, for use with the k7 project (http://github.com/sebastien/k7/)
• V8CGI: incomplete, for use with the v8cgi project (http://code.google.com/p/v8cgi/)

middleware

• Auth: missing
• Cascade: complete
• CommonLogger: complete
• ContentLength: complete
• Deflater: missing
• Directory: missing
• File: complete
• Head: complete
• JSONP: complete
• Lint: mostly complete (needs stream wrappers)
• MethodOverride: complete
• Mock: missing
• Recursive: missing
• ShowExceptions: simple version complete, needs better HTML output
• ShowStatus: missing
• Static: complete
• URLMap: complete

utilities

• jackup: complete
• Request: mostly complete
• Response: mostly complete

Jack currently supports the Jetty (and other servlet containers) and Simple webservers using Rhino. It’s also easy to add support for other webservers.

The current Jack implementation uses Narwhal for support. Narwhal is a JavaScript standard library (based on the ServerJS standard: https://wiki.mozilla.org/ServerJS) and is located at http://narwhaljs.org/

To start working with Jack, follow the Narwhal Quick Start guide, which includes installing Jack.

Then run one of the examples (paths relative to Narwhal installation):

jackup packages/jack/example/example.js
jackup packages/jack/example/comet.js

Or if the current directory contains “jackconfig.js” you can just run “jackup”

jackup

This is equivalent to:

jackup jackconfig.js

A Jackup configuration file is a normal Narwhal module that exports a function called “app”:

exports.app = function(env) {
    return {
        status : 200,
        headers : {"Content-Type":"text/plain"},
        body : ["Hello world!"]
    };
}

If the module also exports a function with the same name as the chosen environment (using the “-E” command line option, “development” by default) that function will be used to apply middleware to your application. This allows you to define custom sets of middleware for different environments. For example:

exports.development = function(app) {
    return Jack.CommonLogger(
        Jack.ShowExceptions(
          Jack.Lint(
            Jack.ContentLength(app))));
}

To see other options of Jackup, use the “-h” option:

jackup -h