1. Computing

List of Rack Middleware

By

The following is a list of Rack middleware applications that come with the Rack gem. A brief description of each middleware is given. For more information, see the Rack documentation.

  • Rack::Cascade - Rack::Cascade will fork a request to multiple apps. When constructed, you pass multiple application instances to it and on each request, it will send the request to all of these apps. Rack::Cascade will return the first response that is not 404 (not found). Rack::Cascade can be useful for trying each request on multiple applications. This can be a quick and dirty way to get around routing and mapping specific URLs to specific Rack apps. However, if more than one app given to Rack::Cascade responds to the same request URL, only the first in the list that responds to that URL will respond.

  • Rack::Chunked - Rack::Chunked will implement HTTP 1.1's Chunked Transfer Encoding. This allows your application generate content without knowing, and without having to count, the content length. This isn't very useful for most applications where responses are small, but this can be useful for large responses, such as sending large files. HTTP 1.1 requires either the Content-Length be properly set or that chunked transfer encoding be used.

  • Rack::CommonLogger - Rack::CommonLogger will log all incoming requests to an apache-style logfile. To the constructor, the next app in the chain is passed as well as a File object to log to. If no File object is passed, the File object created by Rack and stored in env['rack.errors'] will be used. While most HTTP servers support logging, this will give you server-agnostic logging in a common format with a simple piece of middleware.

  • Rack::ConditionalGet - Rack::ConditionalGet will implement HTTP's If-None-Match and If-Modified-Since which allow conditional HTTP requests based on ETAGs and modification dates. If your application's response indicates that the content has not been modified, then Rack::ConditionalGet will discard the response and return a code 304 Not Modified. While this isn't perfect, the server still went through all the work to generate the response, it still saves on bandwidth and is faster for the client. This would be better implemented in the application itself, but Rack::ConditionalGet can be used to implement this feature for any application.

  • Rack::ContentLength - This one is simple, Rack::ContentLength will count the number of bytes in the response and set the HTTP Content-Length header. This header is required, so if your application doesn't generate the content length itself, this middleware app should be used.

  • Rack::ContentType - Rack::ContentType sets the HTTP Content-Type response header. Any sane response to be interpreted by a web browser should have a Content-Type header. This middleware app takes an optional content type string to its constructor. If no content type is supplied, it will use the type text/html. If your application supplies its own content type, Rack::ContentType will not overwrite it.

  • Rack::Deflater - Rack::Deflater will compress the response body with gzip or deflate.

  • Rack::Directory - This is a very useful middleware, it will provide Apache-style "index of" directory listings of files. To its constructor, a root directory is passed. Rack::Directory will serve directory listings and files from this root directory and its sub-directories.

  • Rack::ETag - Rack::ETag will automatically generate digests of your response bodies and generate ETag headers uniquely identifying it. Note that this generates an ETag based on the entire response body. If any peripheral changes are made to response bodies without changes in the actual content (something changed in the header or footer, for example), then the ETag will not be very useful. It may be more useful to generate ETags yourself from within the application. This can be combined with the Rack::ConditionalRequest middleware.

  • Rack::Lint - Rack::Lint checks your responses to make sure they are complete and sane. This is the middleware that generates errors if you fail to set things like Content-Type headers. It's automatically included in all Rackup apps running in development mode. It's been said that the "official" Rack application spec is Rack::Lint.

  • Rack::Reloader - Rack::Reloader implements automatic reloading of your application whenever there are changes made. Using this, you can simply make changes to your application in a text editor, save, and Rack::Reloader will see this on the next request and reload the application before continuing. This is similar to the automatic reloading happening in Rails' development mode.

  • Rack::Sendfile - Rack::Sendfile will set the X-Sendfile header, which will tell web servers that support this to send a file using much faster native code routines, or even system calls like sendfile, which send entire files without leaving kernel-mode. In order for this header to be set, the response body from your application must respond to the to_path method. There is a second parameter that must be passed to Rack::Sendfile defining which set of headers to use. This set of headers will need to match the headers your web server expects.

  • Rack::ShowExceptions - Rack::ShowExceptions will catch all exceptions from applications that it middles for. When an exception is caught, it's formatted in HTML and returned via the web browser. This is especially useful for servers running in development mode.

  • Rack::Static - Rack::Static will intercept requests to certain directories on the server and serve static files instead of passing the request on to the next application. This can be used to serve images, CSS files, etc while still having dynamic applications on the middleware stack. To use Rack::Static, a list of directories to serve must be passed to the constructor.

  • Rack::URLMap - Rack::URLMap deserves an article all to itself. It, combined with Rack::Builder (which you use in Rackup files) can be used to make Rails-style routes that map URLs to different applications. In addition, each route or map can be configured with a separate middleware stack. In other words, Rack::URLMap allows you to easily configure many applications to run on the same Rack, each with their own URL patterns, and each with their own middleware stack.

©2014 About.com. All rights reserved.