1. Rails Request
&
Middlewares
Santosh Wadghule | @mechanicles
BigBinary

2. What is a request?

3. Request is a…
• It is set of instructions that tells a server what kind
of response we want.
• In simple way, when we hit any url in the browser
for some file, that is your actual request :)
• It is a part of HTTP (request/response) protocol.
• HTTP uses one of the verbs like GET, POST,
PUT & DELETE when you perform the request to
the server.

4. Rails Request Life Cycle

5. The Greatest of the Great Greek Geniuses!

6. Rails Request Life Cycle
Browser
Web Server
App Server
Routes
Controller
Model
View
Database
Rails App
Middlewares

7. What is a Web Server?
• Web Server is strictly HTTP based, it just takes
HTTP requests and sends back HTTP responses
to the clients(browsers).
• It is mostly designed to serve static files.
• It also has other functionality like request pipeline,
load balancing etc. App servers lack these
functionalities.
• E.g. Ngnix, Apache

8. What is an App Server?
• App Server actually runs your Rails app.
• App Server is mostly known for to serve dynamic pages.
• Web Server forwards its request to the App Server, and
App Server in turn forwards that request to the Rails app.
• In development mode, App Server can play role of web
server. In production it does not scale too much so we
need web server in between.
• Webrick, Passenger, Mongrel, Unicorn, Thin & etc.

9. Request to Rails app
• Rails isn’t just one application, it has lots of independent Rack
applications (middlewares).
• When request comes to the Rails app, it goes through the list of
middleware series.
• Last part of that series, sends request to the routes file.
• Based on request, Rails decides which controller & action need to be
executed from the routes.
• After executing the controller’s action, Rails sends back response to the
the client.
• Web Server & App Server actually handle the job of sending response to
the proper client.

10. What is a Middleware?
• Middleware is Rack application.
• Middleware is basically a filter for request and
response.
• So middlewares isolate the different stages of
processing on the request and response.

11. Rails Middlewares
Web
Server
Rails App
A B C D
Routes
Controller
Models
Views
Here A, B, C & D are middlewares
Each of these does processing on request & response

12. Why Rails uses Middlewares?
• Before Rails 3, Rails provides, like handling of session,
parsing for parameters and etc were very tightly coupled.
• As Rails was growing, apps built on Rails had more
demanding requirements. For some apps, Rails gave lots
of additional stuffs by default, which was not required like
cookies/flash. For some other apps, to implement new
filter on the the request/response was not possible.
• In Rails 3 and after, all these issues have got solved by
using a concept of Rack.

13. Rack

14. What is a Rack?
• Rack is simple but powerful spec. Yes it is just spec.
• It is not web framework or web server.
• It is an interface that sits between your web server and your application.
It wraps HTTP requests and responses in the simplest way possible, it
unifies and distills the API for web servers, web frameworks and
software in between (i.e. middleware) into a single method call.
• Specification: A Rack application is a Ruby object (not a class) that
responds to `call`. It takes exactly one argument, the environment
and returns an Array of three values, The status, the headers, and the
body. That’s it.
• Rack is created by Christian Neukirchen.

15. Simple Rack App

16. Rack it up

17. What is Rack::Builder?
• Rack::Builder implements a small DSL to iteratively
construct Rack applications.
• Rack::Builder is the thing that glues Rack middlewares and
application together and convert them into single entity/rack
application.
• Under the hood, ‘rackup’ command converts your config.ru
script to an instance of Rack::Builder.
• Think of Rack::Builder object as stack in which your actual
rack application is at bottom and all middlewares on top of
it. The whole stack you can call it as rack application too.

18. Rails’ Rack::Builder
• Same like Rack::Builder, we have similar concept in Rails,
it is called as ActionDispatch::MiddlewareStack.
• Better flexibility and more features to meet Rails’
requirement.
• Many of Action Dispatcher’s internal components are
implemented as Rack middleware.
• Rails::Application uses
ActionDispatch::MiddlewareStack to combine various
internal and external middlewares to form a complete Rails
Rack application.

19. Inspecting Rails Middlewares
• Rails provides a task for inspecting the
middleware stack in use.
• $ bin/rake middleware

20. $ bin/rake middleware
Note: List of the middlewares may be different for your Rails app

21. Request’s entry to MVC
• When request comes to your Rails app, it goes
through these middlewares. From top to
bottom.
• At the bottom, request enters into the your
Rails’ MVC area.

22. Lets go through these middlewares and
understand what these middlewares do

23. Rack::Sendfile
• Sets server specific X-Sendfile header.
• Configure this via
config.action_dispatch.x_sendfile_header option
• The Sendfile middleware 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 reduces the amount of work required by the Ruby
backend and takes advantage of the web server's
optimized file delivery code.

24. ActionDispatch::Static
• This middleware will attempt to return the
contents of a file's body from disk in the
response. If a file is not found on disk, the
request will be delegated to the application
stack. This middleware is commonly initialized
to serve assets from a server's `public/`
directory.
• Used to serve static files. Disabled if
config.serve_static_files is false.

25. Rack::Lock
• Sets env["rack.multithread"] flag to false
and wraps the application within a Mutex.
• Rack::Lock locks every request inside a mutex,
so that every request will effectively be
executed synchronously.

26. ActiveSupport::Cache::Strategy::LocalCache::Middleware
• From doc It says, “Caches that implement
LocalCache will be backed by an in-memory
cache for the duration of a block. Repeated
calls to the cache for the same key will hit the
in-memory cache for faster access”.
• This cache is not thread safe.

27. Rack::Runtime
• Sets an "X-Runtime" response header,
indicating the response time of the request, in
seconds.

28. Rack::MethodOverride
• Allows the method to be overridden if
params[:_method] is set. This is the middleware
which supports the PUT and DELETE HTTP method
types.
• Rails forms convert PUT/DELTE request into the
POST request and passes the param[:_method]
which may be has values like ‘PUT’ & ‘DELETE’ etc.
• Then this middle converts the post request, into
proper request PUT/DELETE which user has initiated
for.

29. ActionDispatch::RequestId
• Assigns a unique id to the request.
• Sends back this unique id in X-Request-ID
response header.

30. Rails::Rack::Logger
• Notifies the logs that the request has began.
After request is complete, flushes all the logs.

31. ActionDispatch::ShowExceptions
• This middleware rescues any exception
returned by the application and calls an
exceptions app that will wrap it in a format for
the end user.

32. ActionDispatch::DebugExceptions
• This middleware is responsible for logging
exceptions and showing a debugging page in
case the request is local.

33. ActionDispatch::RemoteIp
• It captures the remote IP address.
• Checks for IP spoofing attacks.

34. ActionDispatch::Reloader
• Provides prepare and cleanup callbacks,
intended to assist with code reloading during
development.

35. ActionDispatch::Callbacks
• Provides callbacks to be executed before and
after dispatching the request.

36. ActiveRecord::Migration::CheckPending
• Checks pending migrations and raises
ActiveRecord::PendingMigrationError if any
migrations are pending.

37. ActiveRecord::ConnectionAdapters::ConnectionManagement
• Cleans active connections after each request.
• It will not clean the active connections if
env[‘rack.test’] set to true.

38. ActiveRecord::QueryCache
• Enables the Active Record query cache for
request.
• It clears the cache after executing the request.

39. ActionDispatch::Cookies
• Sets cookies for the request.

40. ActionDispatch::Session::CookieStore
• Responsible for storing the session in cookies.
• It is dramatically faster than the alternatives.

41. ActionDispatch::Flash
• Sets up the flash keys.
• Only available if
config.action_controller.session_store is
set to a value.

42. ActionDispatch::ParamsParser
• Parses out parameters from the request into
params.

43. Rack::Head
• Rack::Head returns an empty body for all
HEAD requests. It leaves all other requests
unchanged.
• Converts HEAD requests to GET requests and
serves them as so.

44. Rack::ConditionalGet
• Adds support for "Conditional GET" so that
server responds with nothing if page wasn't
changed.

45. Rack::ETag
• Adds ETag header on all String bodies. ETags
are used to validate cache.

46. Warden::Manager
• The middleware for Rack Authentication.
• It injects an authentication object into the rack
environment hash

47. Rack::Deflater
• This middleware enables compression of http
responses.
• Supports these compression algorithms(gzip,
deflate, identity)

48. RailsRequest::Application.routes
• Here RailsRequest will be different based on your Rails app
• This code returns the instance of ActionDispatch::Routing::RouteSet class
which is also a Rack application.
• After this, request goes to config/routes.rb file and from there it enters into
your MVC.
• Controller creates response & sends back it again to these middlewares stack.
• Middlewares may be can filter that response if necessary.
• Finally response goes to client through the app server & web server.
• How does Rails handle the routes and create the response in a way of [status,
header, body]? Well, that’s the topic for another talk.

49. Thanks :)