A List of Middleware Used by Rails

3 min read

Here’s a list of middleware Rails uses in a development environment. You can view the middleware by running the bin/rails middleware command from your application directory.


Displays speed badge for every HTML page. Designed to work both in production and in development.


Guards from DNS rebinding attacks by explicitly permitting the hosts a request can be sent to


Intercepts responses whose body is being served from a file and replaces it with a server specific X-Sendfile header. The web server is then responsible for writing the file contents to the client.

This can dramatically reduce the amount of work required by the Ruby backend and takes advantage of the web server’s optimized file delivery code.


Serves static files from disk, if available. If no file is found, it hands off to the main app. In Rails apps, this middleware is configured to serve assets from the public directory.


Wraps requests with a supplied Executor. The Rails Executor separates application code from framework code. Any time the framework invokes your code, it will be wrapped by the executor.

The Executor consists of two callbacks: to_run and to_complete. The Run callback is called before the application code, and the Complete callback is called after.


Flushes memory based store used internally by Rails.cache


Sets an “X-Runtime” response header, indicating the response time of the request, in seconds. You can put it right before the application to see the processing time, or before all the other middlewares to include time for them, too.


HTML forms only support the GET and POST request. This middleware lets you override based on _method parameter, allowing you to use PUT or DELETE.

Makes a unique request id available to the action_dispatch.request_id env variable and sends the same id to the client via the X-Request-Id header.


The unique request id is either based on the X-Request-Id header in the request, which would typically be generated by a firewall, load balancer, or the web server, or, if this header is not available, a random uuid.

The unique request id can be used to trace a request end-to-end and would typically end up being part of log files from multiple pieces of the stack.


Calculates the IP address of the remote client that is making the request. Read more at: https://blog.gingerlime.com/2012/rails-ip-spoofing-vulnerabilities-and-protection/


Suppresses logger output for asset requests.


Sets log tags, logs the request, calls the app, and flushes the logs.


This middleware rescues any exception returned by the application and calls an exceptions app that will wrap it in a format suitable for the the end-user.


Sets up an interactive Ruby session in your browser.


Logs exceptions and shows a debugging page in case the request is local.


Takes care of invoking actions from error page. Dispatches action to ActionableError and redirects back when action block has successfully run.

Source: https://www.bigbinary.com/blog/rails-6-adds-active-support-actionable-error


Ensures any arriving HTTP request is served with a freshly-loaded copy of the application if there are any new code changes.


Provides callbacks to be executed before and after dispatching the request.


Verifies that all migrations have been run before loading a web page if config.active_record.migration_error is set to :page_load


It reads and writes data to cookies through ActionController#cookies. When reading cookie data, the data is read from the HTTP request header, Cookie. When writing cookie data, the data is sent out in the HTTP response header, Set-Cookie.


Stores the session in a cookie so it persists between requests. This cookie-based session store is the Rails default and it is dramatically faster than the alternatives.


Provides a way to pass temporary primitive-types (String, Array, Hash) between actions.

Anything you place in the flash will be exposed to the very next action and then cleared out. This is a great way of doing notices and alerts.


Helps setting up the content-security-policy for your app, to guard against Cross-Site-Scripting attacks.


Helps setting up the HTTP Permissions policy for defining a mechanism to allow and deny the use of browser permissions in its own context.


Returns an empty body for all HEAD requests, leaving all other requests unchanged.

The HTTP HEAD method requests the headers that would be returned for a GET request with same URL. For example, if a URL might produce a large download, a HEAD request could read its Content-Length header to check the filesize without actually downloading the file.


Enables conditional GET using If-None-Match and If-Modified-Since. If response is the same as last request, it won’t send the last data again.


Automatically sets the ETag header on all String bodies.


Tracks and cleans the temporary files created throughout a request.


Runs our application.