Times how long it takes for the application to respond to the request and sets that to the X-Runtime header of the response. Also allows the user to provide a suffix, so that different things can be timed, eg, the just the app, or the app plug middleware stack. use Rack::Runtime, "All" # use more middleware's here use Rack::Runtime, "App" run Application will set "X-Runtime-All" and "X-Runtime-App" headers on the response. Signed-off-by: Joshua Peek <firstname.lastname@example.org>
Modifies response headers for client and proxy caching of static files that minimizes http requests and improves overall load times for second time visitors. Signed-off-by: Ryan Tomayko <email@example.com>
Transforms relative paths in redirects to absolute URLs. This allows your web applications to use simple relative paths in their redirects if they want, so they don't have to worry about the url scheme, server name, or port. Absolute URLs are not modified. This uses a sensible default based on the environment, but gives the user full control by allowing them to specify a block that provides the absolute part of the url (e.g. http://example.org). Currently, this only takes affect if the response code is 301-303, I'm not sure if other status codes should be considered, but they should be easy to add if so. Also, this currently only considers Locations starting with http:// or https:// as absolute URLs. If other protocol schemes should be considered, those can be added later. This code will fail if the Location includes the server name part but not the protocol scheme (e.g. Location: //example.org/path). If those should be allowed, we can do so, but that's also a valid relative path, so it's not without its problems. This implementation works with both relative and absolute paths. If a relative path is given (not starting with a slash), it is made relative to the request path. I'm not sure if this works perfectly, though it passes the specs I wrote.
The included RDoc gives a good description of the use of this. Basically, successful responses for GET requests without query strings are cached either to disk or to a user provided ruby object (such as a hash or memcache). In the most basic form, this does basically the same thing as Rails' page caching, but there is a lot more flexibility, since you can provide your own cache object as well as the block that maps request paths to file system paths or cache keys.