The Book

Table of Contents
Introduction
Routes
Handlers
Filters
- before do…
- Handling of Rails like nested params (Sinatra <= 0.3.0)
Views
Models
Helpers
- The basics
- Implemention of rails style partials
Rack Middleware
Error Handling
Configuration
Deployment
Contributing

Introduction

What is Sinatra?

Sinatra is a Domain Specific Language (DSL) for quickly creating web-applications in Ruby.

It keeps a minimal feature set, leaving the developer to use the tools that best suit them and their application.

It doesn’t assume much about your application, apart from that:

it will be written in Ruby programming language
it will have URLs

In Sinatra, you can write short ad hoc applications or mature, larger application with the same easiness. (See section “Real World Applications” later in this book.)

You can use the power of various Rubygems and other libraries for Ruby available.

Sinatra really shines when used for experiments and application mock-ups or for creating a quick interface for your code.

It isn’t a typical Model-View-Controller framework, but ties specific URL directly to relevant Ruby code and returns its output in response. It does enable you, however, to write clean, properly organized applications: separating views from application code, for instance.

Installation

The simplest way to obtain Sinatra is through Rubygems

$ sudo gem install sinatra

Dependencies

Sinatra depends on the Rack gem (http://rack.rubyforge.org).

For optimal experience, you should also install the Haml (http://haml.hamptoncatlin.com) and Builder gem (http://builder.rubyforge.org), which simplifies working with views.

$ sudo gem install builder haml

Living on the Edge

The edge version of Sinatra lives in its Git repository, available at http://github.com/sinatra/sinatra/tree/master.

You can use the edge version to try new functionality or to contribute to the framework. You need to have Git version control software installed (http://www.git-scm.com). Then follow these steps:

cd where/you/keep/your/projects
git clone git://github.com/sinatra/sinatra.git
cd sinatra
cd your_project
ln -s ../sinatra

Then add this to your application:

$:.unshift File.dirname(__FILE__) + '/sinatra/lib'
require 'sinatra'

You can check the version you are running by adding this route

get '/about' do
  "I'm running on Version " + Sinatra::VERSION
end

and loading http://localhost:4567/about in your browser.

Hello World Application

Sinatra is installed and you’re done eating cake, how about making your first application?

# hello_world.rb
require 'rubygems'
require 'sinatra'

get '/' do
  "Hello world, it's #{Time.now} at the server!"
end

Run this application by $ ruby hello_world.rb and load http://localhost:4567 in your browser.

As you can see, Sinatra doesn’t force you to setup much infrastructure: a request to some URL (root URL in this case) evaluates some Ruby code and returns some text in response.

Real World Applications in Sinatra

Github Services

Git hosting provider Github uses Sinatra for post-receive hooks, calling user specified services/URLs, whenever someone pushes to their repository:

Git Wiki

Git Wiki is minimal Wiki engine powered by Sinatra and Git. See also various forks with additional functionality.

Integrity

Integrity is small and clean continuous integration service using Sinatra, watching for failing builds of your codebase and notifying you by various channels.

Seinfeld Calendar

Seinfeld Calendar is a fun application tracking your contributions to open-source projects, displaying your “streaks”, ie. continuous commits to Github repositories.

About this book

This book will assume you have a basic knowledge of the Ruby scripting language and a working Ruby interpreter.

For more information about the Ruby language visit the following links:

Routes

HTTP methods

Sinatra’s routes are designed to respond to the HTTP request methods.

GET
POST
PUT
DELETE

Basic

Simple

get '/hi' do
  ...
end

With params

get '/:name' do
  # matches /sinatra and the like and sets params[:name]
end

Options

Splats

get '/say/*/to/*' do
  # matches /say/hello/to/world
  params["splat"] # => ["hello", "world"]
end

get '/download/*.*' do
  # matches /download/path/to/file.xml
  params["splat"] # => ["path/to/file", "xml"]
end

User agent

get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
  "You're using Songbird version #{params[:agent][0]}"
end

get '/foo' do
  # matches non-songbird browsers
end

Other methods

Other methods are requested exactly the same as “get” routes. You simply use the post, put, or delete functions to define the route, rather then the get one. To access POSTed parameters, use params[:xxx] where xxx is the name of the form element that was posted.

post '/foo' do
  "You just asked for foo, with post param bar equal to #{params[:bar]}"
end

The PUT and DELETE methods

Since browsers don’t natively support the PUT and DELETE methods, a hacky workaround has been adopted by the web community. Simply add a hidden element with the name “_method” and the value equal to the HTTP method you want to use. Although the form itself is sent as a POST, Sinatra will interpret the request as the desired method. For example, this form:

<form method="post" action="/destroy_it">
  <input name="_method" value="delete" />
  <div><button type="submit">Destroy it</button></div>
</form>

Will trigger the following route:

delete '/destroy_it' do
  # Your code
end

Note that subclassed Sinatra apps will need to enable this functionality with the line enable :methodoverride.

When you want to use PUT or DELETE from a client that does support them (like Curl, or ActiveResource), just go ahead and use them as you normally would, and ignore the _method advice above. That is only for hacking in support for browsers.

How routes are looked up

Each time you add a new route to your application, it gets compiled down into a regular expression that will match it. That is stored in an array along with the handler block attached to that route.

When a new request comes in, each regex is run in turn, until one matches. Then the the handler (the code block) attached to that route gets executed.

Splitting into multiple files

Because Sinatra clears out your routes and reloads your application on every request in development mode, you can’t use require to load files containing your routes because these will only be loaded when the application starts (and reloaded even on the first request!) Instead, use load:

# application.rb
require 'rubygems'
require 'sinatra'

get '/' do
  "Hello world!"
end

load 'more_routes.rb'

and

# more_routes.rb

get '/foo' do
  "Bar?  How unimaginative."
end

Handlers

Structure

Handler is the generic term that Sinatra uses for the “controllers”. A handler is the initial point of entry for new HTTP requests into your application.

To find more about the routes, head to the Routes section

Form parameters

In handlers you can access submitted form parameters directly via the params hash:

get '/' do
  params['post']
end

Nested form parameters

The support for Rails-like nested parameters has been built-in since Sinatra version 0.9.0. Before this version you had to implement this functionality as a before filter!

<form>
  <input ... name="post[title]" />
  <input ... name="post[body]" />
  <input ... name="post[author]" />
</form>

The parameters in this case became as a hash:

{"post"=>{ "title"=>"", "body"=>"", "author"=>"" }}

Therefore in handlers you can use nested parameters like a regular hash:

params['post']['title']

Redirect

The redirect helper is a shortcut to a common http response code (302).

Basic usage is easy:

redirect '/'

redirect '/posts/1'

redirect 'http://www.google.com'

The redirect actually sends back a Location header to the browser, and the browser makes a followup request to the location indicated. Since the browser makes that followup request, you can redirect to any page, in your application, or another site entirely.

The flow of requests during a redirect is: Browser → Server (redirect to ’/’) → Browser (request ’/’) → Server (result for ’/’)

To force Sinatra to send a different response code, it’s very simple:

redirect '/', 303 # forces the 303 return code

redirect '/', 307 # forces the 307 return code

Sessions

Default Cookie Based Sessions

Sinatra ships with basic support for cookie-based sessions. To enable it in a configure block, or at the top of your application, you just need to enable the option.

enable :sessions

get '/' do
  session["counter"] ||= 0
  session["counter"] += 1

  "You've hit this page #{session["counter"]} time(s)"
end

The downside to this session approach is that all the data is stored in the cookie. Since cookies have a fairly hard limit of 4 kilobytes, you can’t store much data. The other issue is that cookies are not tamper proof - the user can change any data in their session. But… it is easy, and it doesn’t have the scaling problems that memory or database backed sessions run into.

Memory Based Sessions

Memcached Based Sessions

File Based Sessions

Database Based Sessions

Cookies

Cookies are a fairly simple thing to use in Sinatra, but they have a few quirks.

Lets first look at the simple use case:

require 'rubygems'
require 'sinatra'

get '/' do
    # Get the string representation
    cookie = request.cookies["thing"]

    # Set a default
    cookie ||= 0

    # Convert to an integer
    cookie = cookie.to_i

    # Do something with the value
    cookie += 1

    # Reset the cookie
    set_cookie("thing", cookie)

    # Render something
    "Thing is now: #{cookie}"
end

Setting a path, expiration date, or domain gets a little more complicated - see the source code for set_cookie if you want to dig deeper.

set_cookie("thing", :domain => myDomain,
                    :path => myPath,
                    :expires => Date.new)

That’s the easy stuff with cookies - It can also serialize Array objects, separating them with ampersands (&), but when they come back, it doesn’t deserialize or split them in any way, it hands you the raw, encoded string for your parsing pleasure.

Status

If you want to set your own status response instead of the normal 200 (Success), you can use the status-helper to set the code, and then still render normally:

get '/' do
  status 404
  "Not found"
end

Alternatively you can use throw :halt, [404, "Not found"] to immediately stop any further actions and return the specified status code and string to the client. throw supports more options in this regard, see the appropriate section for more info.

Authentication

Filters

before do…

These are run in Sinatra::EventContext

before do
  # .. this code will run before each event ..
end

Handling of Rails like nested params (Sinatra <= 0.3.0)

If you want to use a form with parameters like this (aka. Rails’ nested params):

<form>
  <input ... name="post[title]" />
  <input ... name="post[body]" />
  <input ... name="post[author]" />
</form>

You have convert parameters to a hash. You can easily do this with a before filter:

before do
  new_params = {}
  params.each_pair do |full_key, value|
    this_param = new_params
    split_keys = full_key.split(/\]\[|\]|\[/)
    split_keys.each_index do |index|
      break if split_keys.length == index + 1
      this_param[split_keys[index]] ||= {}
      this_param = this_param[split_keys[index]]
   end
   this_param[split_keys.last] = value
  end
  request.params.replace new_params
end

Then parameters became:

{"post"=>{ "title"=>"", "body"=>"", "author"=>"" }}

Views

All file-based views are looked up in:

root
  | - views/

Template Languages

Haml

get '/' do
  haml :index
end

This will render ./views/index.haml

Sass

get '/' do
  sass :styles
end

This will render ./views/styles.sass

Erb

get '/' do
  erb :index
end

This will render ./views/index.erb

Builder

get '/' do
  builder :index
end

This will render ./views/index.builder

get '/' do
  builder do |xml|
    xml.node do
      xml.subnode "Inner text"
    end
  end
end

This will render the xml inline, directly from the handler.

Atom Feed

RSS Feed

Assume that your site url is http://liftoff.msfc.nasa.gov/.

get '/rss.xml' do
  builder do |xml|
    xml.instruct! :xml, :version => '1.0'
    xml.rss :version => "2.0" do
      xml.channel do
        xml.title "Liftoff News"
        xml.description "Liftoff to Space Exploration."
        xml.link "http://liftoff.msfc.nasa.gov/"
        
        @posts.each do |post|
          xml.item do
            xml.title post.title
            xml.link "http://liftoff.msfc.nasa.gov/posts/#{post.id}"
            xml.description post.body
            xml.pubDate Time.parse(post.created_at.to_s).rfc822()
            xml.guid "http://liftoff.msfc.nasa.gov/posts/#{post.id}"
          end
        end
      end
    end
  end
end

This will render the rss inline, directly from the handler.

Layouts

Layouts are simple in Sinatra. Put a file in your views directory named “layout.erb”, “layout.haml”, or “layout.builder”. When you render a page, the appropriate layout will be grabbed (of the same filetype), and used.

The layout itself should call yield at the point you want the content to be included.

An example haml layout file could look something like this:

%html
  %head
    %title SINATRA BOOK
  %body
    #container
      = yield

Avoiding a layout

Sometimes you don’t want the layout rendered. In your render method just pass

layout => false, and you’re good.

get ’/’ do haml :index, :layout => false end

In File Views

This one is cool:

get '/' do
  haml :index
end

use_in_file_templates!

__END__

@@ layout
X
= yield
X

@@ index
%div.title Hello world!!!!!

Try it!

Partials

Models

Datamapper

Start out by getting the DataMapper gem if you don’t already have it, and then making sure it’s in your applicaton. A call to setup as usual will get the show started, and this example will include a ‘Post’ model.

require 'rubygems'
require 'sinatra'
require 'datamapper'

DataMapper::setup(:default, "sqlite://#{Dir.pwd}/blog.db")

class Post
    include DataMapper::Resource
    property :id, Serial
    property :title, String
    property :body, Text
    property :created_at, DateTime
end

# automatically create the post table
Post.auto_migrate! unless Post.table_exists?

Once that is all well and good, you can actually start developing your application!

get '/' do
    # get the latest 20 posts
    @posts = Post.get(:order => [ :id.desc ], :limit => 20)
    erb :index
end

Finally, the view at ./view/index.html:

<% for post in @posts %>
    <h3><%= post.title %></h3>
    <p><%= post.body %></p>
<% end %>

Sequel

Require the Sequel gem in your app:

require 'rubygems'
require 'sinatra'
require 'sequel'

Use a simple in-memory DB:

DB = Sequel.sqlite

Create a table:

DB.create_table :links do
 primary_key :id
 varchar :title
 varchar :link
end

Create the Model class:

class Link < Sequel::Model
end

Create the route:

get '/' do
 @links = Link.all
 haml :links
end

ActiveRecord

First require ActiveRecord gem in your application, then give your database connection settings:

require 'rubygems'
require 'sinatra'
require 'activerecord'

ActiveRecord::Base.establish_connection(
  :adapter => 'sqlite3',
  :dbfile =>  'sinatra_application.sqlite3.db'
)

Now you can create and use ActiveRecord models just like in Rails (the example assumes you already have a ‘posts’ table in your database):

class Post < ActiveRecord::Base
end

get '/' do
  @posts = Post.all()
  erb :index 
end

This will render ./views/index.erb:

<% for post in @posts %>
  <h1><%= post.title %></h1>
<% end %>

Helpers

The basics

It is ill-advised to create helpers on the root level of your application. They muddy the global namespace, and don’t have easy access to the request, response, session or cookie variables.

Instead, use the handy helpers method to install methods on Sinatra::EventContext for use inside events and templates.

Example:

helpers do
  def bar(name)
    "#{name}bar"
  end
end

get '/:name' do
  bar(params[:name])
end

Implemention of rails style partials

Using partials in your views is a great way to keep them clean. Since Sinatra takes the hands off approach to framework design, you’ll have to implement a partial handler yourself.

Here is a really basic version:

# Usage: partial :foo
helpers do
  def partial(page, options={})
    haml page, options.merge!(:layout => false)
  end
end

A more advanced version that would handle passing local options, and looping over a hash would look like:

# Render the page once:
# Usage: partial :foo
# 
# foo will be rendered once for each element in the array, passing in a local variable named "foo"
# Usage: partial :foo, :collection => @my_foos    

helpers do
  def partial(template, *args)
    options = args.extract_options!
    options.merge!(:layout => false)
    if collection = options.delete(:collection) then
      collection.inject([]) do |buffer, member|
        buffer << haml(template, options.merge(
                                  :layout => false, 
                                  :locals => {template.to_sym => member}
                                )
                     )
      end.join("\n")
    else
      haml(template, options)
    end
  end
end

Rack Middleware

Sinatra rides on Rack, a minimal standard interface for Ruby web frameworks. One of Rack’s most interesting capabilities for application developers is support for “middleware” – components that sit between the server and your application monitoring and/or manipulating the HTTP request/response to provide various types of common functionality.

Sinatra makes building Rack middleware pipelines a cinch via a top-level use method:

require 'sinatra'
require 'my_custom_middleware'

use Rack::Lint
use MyCustomMiddleware

get '/hello' do
  'Hello World'
end

The semantics of “use” are identical to those defined for the Rack::Builder DSL (most frequently used from rackup files). For example, the use method accepts multiple/variable args as well as blocks:

use Rack::Auth::Basic do |username, password|
  username == 'admin' && password == 'secret'
end

Rack is distributed with a variety of standard middleware for logging, debugging, URL routing, authentication, and session handling. Sinatra uses many of of these components automatically based on configuration so you typically don’t have to use them explicitly.

Error Handling

not_found

Remember: These are run inside the Sinatra::EventContext which means you get all the goodies is has to offer (i.e. haml, erb, :halt, etc.)

Whenever NotFound is raised this will be called

not_found do
  'This is nowhere to be found'
end

error

By default error will catch Sinatra::ServerError

Sinatra will pass you the error via the ‘sinatra.error’ in request.env

error do
  'Sorry there was a nasty error - ' + request.env['sinatra.error'].name
end

Custom error mapping:

error MyCustomError do
  'So what happened was...' + request.env['sinatra.error'].message
end

then if this happens:

get '/' do
  raise MyCustomError, 'something bad'
end

you gets this:

So what happened was... something bad

Additional Information

Because Sinatra give you a default not_found and error do :production that are secure. If you want to customize only for :production but want to keep the friendly helper screens for :development then do this:

configure :production do
  not_found do
    "We're so sorry, but we don't what this is"
  end

  error do
    "Something really nasty happened.  We're on it!"
  end
end

Configuration

Use Sinatra’s “set” option

Configure blocks are not executed in the event context, and don’t have access to the same instance variables. To store a piece of information that you want to access in your routes, use set.

configure :development do
  set :dbname, 'devdb'
end

configure :production do
  set :dbname, 'productiondb'
end

…

get '/whatdb' do
  'We are using the database named ' + options.dbname
end

External config file via the configure block

Application module / config area

Deployment

Heroku

This is the easiest configuration + deployment option. Heroku has full support for Sinatra applications. Deploying to Heroku is simply a matter of pushing to a remote git repository.

Steps to deploy to Heroku:

Create an account if you don’t have one
sudo gem install heroku
Make a config.ru in the root-directory
Create the app on heroku
Push to it

An example config.ru file (Heroku sets RACK_ENV to production for you)
```
require "myapp"

run Sinatra::Application
```

Create the app and push to it

From the root-directory of the application

$ heroku create <app-name>  # This will add heroku as a remote
$ git push heroku master

For more details see this

Lighttpd Proxied to Thin

This will cover how to deploy Sinatra to a load balanced reverse proxy setup using Lighttpd and Thin.

Install Lighttpd and Thin

# Figure out lighttpd yourself, it should be handled by your 
# linux distro's package manager
 
# For thin:
gem install thin

Create your rackup file – the require 'app' line should require the actual Sinatra app you have written.

## This is not needed for Thin > 1.0.0
ENV['RACK_ENV'] = "production"

require 'app'

run Sinatra::Application

Setup a config.yml - change the /path/to/my/app path to reflect reality.

---
  environment: production
  chdir: /path/to/my/app
  address: 127.0.0.1
  user: root
  group: root
  port: 4567
  pid: /path/to/my/app/thin.pid
  rackup: /path/to/my/app/config.ru
  log: /path/to/my/app/thin.log
  max_conns: 1024
  timeout: 30
  max_persistent_conns: 512
  daemonize: true

Setup lighttpd.conf - change mydomain to reflect reality. Also make sure the first port here matches up with the port setting in config.yml.

$HTTP["host"] =~ "(www\.)?mydomain\.com"  {
        proxy.balance = "fair"
        proxy.server =  ("/" =>
                                (
                                        ( "host" => "127.0.0.1", "port" => 4567 ),
                                        ( "host" => "127.0.0.1", "port" => 4568 )
                                )
                        )
}

Start thin and your application. I have a rake script so I can just call “rake start” rather than typing this in.
```
thin -s 2 -C config.yml -R config.ru start
```

You’re done! Go to mydomain.com/ and see the result! Everything should be setup now, check it out at the domain you setup in your lighttpd.conf file.

Variation - nginx via proxy - The same approach to proxying can be applied to the nginx web server

upstream www_mydomain_com {
  server 127.0.0.1:5000;
  server 127.0.0.1:5001;
}

server {
  listen    www.mydomain.com:80
  server_name  www.mydomain.com live;
  access_log /path/to/logfile.log
  
  location / {
    proxy_pass http://www_mydomain_com;
  }
  
}

Variation - More Thin instances - To add more thin instances, change the -s 2 parameter on the thin start command to be how ever many servers you want. Then be sure lighttpd proxies to all of them by adding more lines to the proxy statements. Then restart lighttpd and everything should come up as expected.

Passenger (mod rails)

Hate deployment via FastCGI? You’re not alone. But guess what, Passenger supports Rack; and this book tells you how to get it all going.

You can find additional documentation at the Passenger Github repository.

Setting up the account in the Dreamhost interface

Domains -> Manage Domains -> Edit (web hosting column)
Enable 'Ruby on Rails Passenger (mod_rails)'
Add the public directory to the web directory box. So if you were using 'rails.com', it would change to 'rails.com/public'
Save your changes

Creating the directory structure

domain.com/
domain.com/tmp
domain.com/public
# a vendored version of sinatra - not necessary if you use the gem
domain.com/sinatra

Creating the “Rackup file” (rack configuration file) config.ru – the require 'app' line should require the actual Sinatra app you have written.
```
## Passenger should set RACK_ENV for Sinatra

require 'app'

run Sinatra::Application
```

A very simple Sinatra application

# this is test.rb referred to above
get '/' do
  "Worked on dreamhost"
end
 
get '/foo/:bar' do
  "You asked for foo/#{params[:bar]}"
end

And that’s all there is to it! Once it’s all setup, point your browser at your domain, and you should see a ‘Worked on Dreamhost’ page. To restart the application after making changes, you need to run touch tmp/restart.txt.

Please note that currently passenger 2.0.3 has a bug where it can cause Sinatra to not find the view directory. In that case, add :views => '/path/to/views/' to the Sinatra options in your Rackup file.

You may encounter the dreaded “Ruby (Rack) application could not be started” error with this message “can’t activate rack (>= 0.9.1, < 1.0, runtime), already activated rack-0.4.0”. This happens because DreamHost has version 0.4.0 installed, when recent versions of Sinatra require more recent versions of Rack. The solution is to explicitly require the rack and sinatra gems in your config.ru. Add the following two lines to the start of your config.ru file:

   require '/home/USERNAME/.gem/ruby/1.8/gems/rack-VERSION-OF-RACK-GEM-YOU-HAVE-INSTALLELD/lib/rack.rb'
   require '/home/USERNAME/.gem/ruby/1.8/gems/sinatra-VERSION-OF-SINATRA-GEM-YOU-HAVE-INSTALLELD/lib/sinatra.rb'

FastCGI

The standard method for deployment is to use Thin or Mongrel, and have a reverse proxy (lighttpd, nginx, or even Apache) point to your bundle of servers.

But that isn’t always possible. Cheaper shared hosting (like Dreamhost) won’t let you run Thin or Mongrel, or setup reverse proxies (at least on the default shared plan).

Luckily, Rack supports various connectors, including CGI and FastCGI. Unluckily for us, FastCGI doesn’t quite work with the current Sinatra release without some tweaking.

Deployment with Sinatra version 0.9

From version 9.0 Sinatra requires Rack 0.9.1, however FastCGI wrapper from this version seems not working well with Sinatra unless you define your application as a subclass of Sinatra::Application class and run this application directly as a Rack application.

Steps to deploy via FastCGI:

htaccess
subclass your application as Sinatra::Application
dispatch.fcgi

.htaccess

 RewriteEngine on
 
 AddHandler fastcgi-script .fcgi
 Options +FollowSymLinks +ExecCGI
 
 RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

Subclass your application as Sinatra::Application

 # my_sinatra_app.rb
 class MySinatraApp < Sinatra::Application
   # your sinatra application definitions
 end

dispatch.fcgi - Run this application directly as a Rack application

 #!/usr/local/bin/ruby

 require 'rubygems'
 require 'rack'
 
 fastcgi_log = File.open("fastcgi.log", "a")
 STDOUT.reopen fastcgi_log
 STDERR.reopen fastcgi_log
 STDOUT.sync = true

 module Rack
   class Request
     def path_info
       @env["REDIRECT_URL"].to_s
     end
     def path_info=(s)
       @env["REDIRECT_URL"] = s.to_s
     end
   end
 end

 load 'my\_sinatra\_app.rb'

 builder = Rack::Builder.new do
   map '/' do
     run MySinatraApp.new
   end
 end

 Rack::Handler::FastCGI.run(builder)

Deployment with Sinatra version <= 0.3

In version 0.3 to get a simple ‘hello world’ Sinatra application up and running via FastCGI, you have to pulling down the current Sinatra code, and hacking at it a bit. Don’t worry though, it only requires commenting out a few lines, and tweaking another.

Steps to deploy:

.htaccess
dispatch.fcgi
Tweaked sinatra.rb

.htaccess RewriteEngine on

AddHandler fastcgi-script .fcgi
Options +FollowSymLinks +ExecCGI

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

dispatch.fcgi

#!/usr/bin/ruby

require 'rubygems'
require 'sinatra/lib/sinatra'

fastcgi_log = File.open("fastcgi.log", "a")
STDOUT.reopen fastcgi_log
STDERR.reopen fastcgi_log
STDOUT.sync = true

set :logging, false
set :server, "FastCGI"

module Rack
  class Request
    def path_info
      @env["REDIRECT_URL"].to_s
    end
    def path_info=(s)
      @env["REDIRECT_URL"] = s.to_s
    end
  end
end

load 'app.rb'

sinatra.rb - Replace this function with the new version here (commenting out the puts lines)

def run
  begin
    #puts "== Sinatra has taken the stage on port #{port} for #{env} with backup by #{server.name}"
    require 'pp'
    server.run(application) do |server|
      trap(:INT) do
        server.stop
        #puts "\n== Sinatra has ended his set (crowd applauds)"
      end
    end
  rescue Errno::EADDRINUSE => e
    #puts "== Someone is already performing on port #{port}!"
  end
end

Contributing

How can I clone the Sinatra repository?

First of all, you’ll need the Git version control system. Git is available for all major platforms:

Windows
Mac OS X
Linux and BSD users can usually acquire Git through their Package Management System, e.g. apt-get install git-core on Debian systems.

After that, cloning the Sinatra repository is as easy as typing the following into your command line:

git clone git://github.com/sinatra/sinatra.git

Sinatra