A rundown of the path a request takes until your application receives it.

The preferred way to run Merb is as a Rack application, which makes it compatible with a range of Rack-compliant servers like Thin, Unicorn, plain rackup, etc. The bootloader builds an application from those middleware components (top down, in the order they handle incoming requests):

1. Merb::Rack::Head – Handle HTTP HEAD requests
2. Merb::Rack::ContentLength – Provide Content-length information
3. Merb::Rack::PathPrefix (conditional) – If Merb::Config[:path_prefix] is set, this middleware strips the prefix from incoming requests so you can virtually "mount" your application in a subpath.
4. Merb::Rack::Static – Static file handling. This redirects requests to static assets (CSS, JavaScript) to the ./public directory in your application.
5. Merb::Rack::Application – Main entrypoint into the Merb stack. Requests that have not been handled at this point are handed off to the dispatcher for parsing, routing, and content generation.

If you need to change the structure, you can specify your own in ./config/rack.rb. Contents of that file will be used instead of the default.

(Write me!)

Rack specifies that incoming requests, especially the request bodies, are encoded as "ASCII-8BIT", which is Ruby's way of handling raw binary data without a specific interpretation. The request parser is the interface between that and Merb internals and your application, which should use UTF-8 internally.

Incoming requests are transformed to UTF-8 according to a bunch of RFCs specifying encoding of charsets in 7bit-clean data streams. Relevant starting points for reading are RFCs 822, 2045, 2184 and 2616.

Implementation note: This behaviour is not available in current releases. It is a planned feature for the 1.2 series when running on Ruby 1.9 or other VMs supporting the encoding API.