RubyGems - logstash-filter-cache-redis - Versions diffs - 0.3.1 → 0.3.3 - Mend

logstash-filter-cache-redis 0.3.1 → 0.3.3

Files changed (4178) hide show

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/CONTRIBUTING.md DELETED

@@ -1,100 +0,0 @@
-# Contribute
-Want to show Sinatra some love? Help out by contributing!
-## Found a bug?
-Log it in our [issue tracker][ghi] or send a note to the [mailing list][ml].
-Be sure to include all relevant information, like the versions of Sinatra and
-Ruby you're using. A [gist](http://gist.github.com/) of the code that caused
-the issue as well as any error messages are also very helpful.
-## Need help?
-The [Sinatra mailing list][ml] has over 900 subscribers, many of which are happy
-to help out newbies or talk about potential feature additions. You can also
-drop by the [#sinatra](irc://chat.freenode.net/#sinatra) channel on
-[irc.freenode.net](http://freenode.net).
-## Have a patch?
-Bugs and feature requests that include patches are much more likely to
-get attention. Here are some guidelines that will help ensure your patch
-can be applied as quickly as possible:
-1. **Use [Git](http://git-scm.com) and [GitHub](http://github.com):**
-   The easiest way to get setup is to fork the
-   [sinatra/sinatra repo](http://github.com/sinatra/sinatra/).
-   Or, the [sinatra.github.com repo](http://github.com/sinatra/sinatra.github.com/),
-   if the patch is doc related.
-2. **Write unit tests:** If you add or modify functionality, it must
-   include unit tests. If you don't write tests, we have to, and this
-   can hold up acceptance of the patch.
-3. **Mind the `README`:** If the patch adds or modifies a major feature,
-   modify the `README.md` file to reflect that. Again, if you don't
-   update the `README`, we have to, and this holds up acceptance.
-4. **Update the change log (`CHANGELOG.md`):** The change log helps give an
-   overview of the changes that go into each release, and gives credit
-   where credit is due. We make sure that the change log is up to date
-   before each release, and we always appreciate it when people make
-   it easier to get the release out the door.
-5. **Push it:** Once you're ready, push your changes to a topic branch
-   and add a note to the ticket with the URL to your branch. Or, say
-   something like, "you can find the patch on johndoe/foobranch". We also
-   gladly accept GitHub [pull requests](http://help.github.com/pull-requests/).
-__NOTE:__ _We will take whatever we can get._ If you prefer to attach diffs in
-emails to the mailing list, that's fine; but do know that _someone_ will need
-to take the diff through the process described above and this can hold things
-up considerably.
-## Want to write docs?
-The process for contributing to Sinatra's website, documentation or the book
-is the same as contributing code. We use Git for versions control and GitHub to
-track patch requests.
-* [The sinatra.github.com repo](http://github.com/sinatra/sinatra.github.com/)
-  is where the website sources are managed. There are almost always people in
-  `#sinatra` that are happy to discuss, apply, and publish website patches.
-* [The Book](http://sinatra-book.gittr.com/) has its own [Git
-  repository](http://github.com/sinatra/sinatra-book/) and build process but is
-  managed the same as the website and project codebase.
-* [Sinatra Recipes](http://recipes.sinatrarb.com/) is a community
-  project where anyone is free to contribute ideas, recipes and tutorials. Which
-  also has its own [Git repository](http://github.com/sinatra/sinatra-recipes).
-* [The Introduction](http://www.sinatrarb.com/intro.html) is generated from
-  Sinatra's [README file](http://github.com/sinatra/sinatra/blob/master/README.md).
-* If you want to help translating the documentation, the README is already
-  available in
-  [Japanese](http://github.com/sinatra/sinatra/blob/master/README.ja.md),
-  [German](http://github.com/sinatra/sinatra/blob/master/README.de.md),
-  [Chinese](https://github.com/sinatra/sinatra/blob/master/README.zh.md),
-  [Russian](https://github.com/sinatra/sinatra/blob/master/README.ru.md),
-  [European](https://github.com/sinatra/sinatra/blob/master/README.pt-pt.md) and
-  [Brazilian](https://github.com/sinatra/sinatra/blob/master/README.pt-br.md)
-  Portuguese,
-  [French](https://github.com/sinatra/sinatra/blob/master/README.fr.md),
-  [Spanish](https://github.com/sinatra/sinatra/blob/master/README.es.md),
-  [Korean](https://github.com/sinatra/sinatra/blob/master/README.ko.md), and
-  [Hungarian](https://github.com/sinatra/sinatra/blob/master/README.hu.md).
-  The translations tend to fall behind the English version. Translations into
-  other languages would also be appreciated.
-## Looking for something to do?
-If you'd like to help out but aren't sure how, pick something that looks
-interesting from the [issues][ghi] list and hack on. Make sure to leave a
-comment on the ticket noting that you're investigating (a simple "Taking…" is
-fine).
-[ghi]: http://github.com/sinatra/sinatra/issues
-[ml]: http://groups.google.com/group/sinatrarb/topics "Sinatra Mailing List"

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/Gemfile DELETED

@@ -1,79 +0,0 @@
-# Why use bundler?
-# Well, not all development dependencies install on all rubies. Moreover, `gem
-# install sinatra --development` doesn't work, as it will also try to install
-# development dependencies of our dependencies, and those are not conflict free.
-# So, here we are, `bundle install`.
-#
-# If you have issues with a gem: `bundle install --without-coffee-script`.
-RUBY_ENGINE = 'ruby' unless defined? RUBY_ENGINE
-source 'https://rubygems.org' unless ENV['QUICK']
-gemspec
-gem 'rake', '~> 10.0'
-gem 'rack-test', '>= 0.6.2'
-gem "minitest", "~> 5.0"
-if RUBY_ENGINE == 'jruby'
-  gem 'nokogiri', '!= 1.5.0'
-  gem 'jruby-openssl'
-  gem 'trinidad'
-end
-if RUBY_VERSION < '1.9.3'
-  gem 'activesupport', '~> 3.2'
-  gem 'i18n', '~> 0.6.0'
-else
-  gem 'activesupport', '~> 4.2'
-end
-if RUBY_ENGINE == "ruby"
-  if RUBY_VERSION > '1.9.2'
-    gem 'less', '~> 2.0'
-    gem 'therubyracer'
-    gem 'redcarpet'
-    gem 'wlang', '>= 2.0.1'
-    gem 'bluecloth'
-    gem 'rdiscount'
-    gem 'RedCloth'
-    gem 'puma'
-    gem 'net-http-server'
-    gem 'yajl-ruby'
-    gem 'thin'
-    gem 'slim', '~> 2.0'
-    gem 'coffee-script', '>= 2.0'
-    gem 'rdoc'
-    gem 'kramdown'
-    gem 'maruku'
-    gem 'creole'
-    gem 'wikicloth'
-    gem 'markaby'
-    gem 'radius'
-    gem 'asciidoctor'
-    gem 'liquid', '~> 3.0'
-    gem 'stylus'
-    gem 'rabl'
-    gem 'builder'
-    gem 'erubis'
-    gem 'haml', '>= 3.0'
-    gem 'sass'
-    if RUBY_VERSION < '2.1.0'
-      gem 'nokogiri', '~> 1.6.8'
-    else
-      gem 'nokogiri', '~> 1.7.0'
-    end
-  else
-    gem 'nokogiri', '~> 1.5.11'
-  end
-end
-if RUBY_ENGINE == "rbx"
-  gem 'json'
-  gem 'rubysl'
-  gem 'rubysl-test-unit'
-end
-platforms :ruby_18, :jruby do
-  gem 'json', '~> 1.8' unless RUBY_VERSION > '1.9' # is there a jruby but 1.8 only selector?
-end

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/LICENSE DELETED

@@ -1,23 +0,0 @@
-Copyright (c) 2007, 2008, 2009 Blake Mizerany
-Copyright (c) 2010, 2011, 2012, 2013, 2014, 2015, 2016 Konstantin Haase
-Permission is hereby granted, free of charge, to any person
-obtaining a copy of this software and associated documentation
-files (the "Software"), to deal in the Software without
-restriction, including without limitation the rights to use,
-copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the
-Software is furnished to do so, subject to the following
-conditions:
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
-OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
-HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
-WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
-OTHER DEALINGS IN THE SOFTWARE.

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/README.de.md DELETED

@@ -1,3031 +0,0 @@
-# Sinatra
-*Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
-Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.5).*
-Sinatra ist eine
-[DSL](https://de.wikipedia.org/wiki/Domänenspezifische_Sprache), die das
-schnelle Erstellen von Webanwendungen in Ruby mit minimalem Aufwand
-ermöglicht:
-Sinatra via `rubygems` installieren:
-```shell
-gem install sinatra
-```
-Eine Datei mit dem Namen `myapp.rb` erstellen:
-```ruby
-require 'sinatra'
-get '/' do
-  'Hallo Welt!'
-end
-```
-und im gleichen Verzeichnis ausführen:
-```shell
-ruby myapp.rb
-```
-Die Seite kann nun unter [http://localhost:4567](http://localhost:4567)
-aufgerufen werden.
-## Inhalt
-* [Sinatra](#sinatra)
-    * [Routen](#routen)
-        * [Bedingungen](#bedingungen)
-        * [Rückgabewerte](#rckgabewerte)
-        * [Eigene Routen-Muster](#eigene-routen-muster)
-    * [Statische Dateien](#statische-dateien)
-    * [Views/Templates](#viewstemplates)
-        * [Direkte Templates](#direkte-templates)
-        * [Verfügbare Templatesprachen](#verfgbare-templatesprachen)
-            * [Haml Templates](#haml-templates)
-            * [Erb Templates](#erb-templates)
-            * [Builder Templates](#builder-templates)
-            * [Nokogiri Templates](#nokogiri-templates)
-            * [Sass Templates](#sass-templates)
-            * [SCSS Templates](#scss-templates)
-            * [Less Templates](#less-templates)
-            * [Liquid Templates](#liquid-templates)
-            * [Markdown Templates](#markdown-templates)
-            * [Textile Templates](#textile-templates)
-            * [RDoc Templates](#rdoc-templates)
-            * [AsciiDoc Templates](#asciidoc-templates)
-            * [Radius Templates](#radius-templates)
-            * [Markaby Templates](#markaby-templates)
-            * [RABL Templates](#rabl-templates)
-            * [Slim Templates](#slim-templates)
-            * [Creole Templates](#creole-templates)
-            * [MediaWiki Templates](#mediawiki-templates)
-            * [CoffeeScript Templates](#coffeescript-templates)
-            * [Stylus Templates](#stylus-templates)
-            * [Yajl Templates](#yajl-templates)
-            * [WLang Templates](#wlang-templates)
-        * [Auf Variablen in Templates zugreifen](#auf-variablen-in-templates-zugreifen)
-        * [Templates mit `yield` und verschachtelte Layouts](#templates-mit-yield-und-verschachtelte-layouts)
-        * [Inline-Templates](#inline-templates)
-        * [Benannte Templates](#benannte-templates)
-        * [Dateiendungen zuordnen](#dateiendungen-zuordnen)
-        * [Eine eigene Template-Engine hinzufügen](#eine-eigene-template-engine-hinzufgen)
-        * [Eigene Methoden zum Aufsuchen von Templates verwenden](#eigene-methoden-zum-aufsuchen-von-templates-verwenden)
-    * [Filter](#filter)
-    * [Helfer](#helfer)
-        * [Sessions verwenden](#sessions-verwenden)
-        * [Anhalten](#anhalten)
-        * [Weiterspringen](#weiterspringen)
-        * [Eine andere Route ansteuern](#eine-andere-route-ansteuern)
-        * [Body, Status-Code und Header setzen](#body-status-code-und-header-setzen)
-        * [Response-Streams](#response-streams)
-        * [Logger](#logger)
-        * [Mime-Types](#mime-types)
-        * [URLs generieren](#urls-generieren)
-        * [Browser-Umleitung](#browser-umleitung)
-        * [Cache einsetzen](#cache-einsetzen)
-        * [Dateien versenden](#dateien-versenden)
-        * [Das Request-Objekt](#das-request-objekt)
-        * [Anhänge](#anhnge)
-        * [Umgang mit Datum und Zeit](#umgang-mit-datum-und-zeit)
-        * [Nachschlagen von Template-Dateien](#nachschlagen-von-template-dateien)
-        * [Konfiguration](#konfiguration)
-            * [Einstellung des Angriffsschutzes](#einstellung-des-angriffsschutzes)
-            * [Mögliche Einstellungen](#mgliche-einstellungen)
-    * [Umgebungen](#umgebungen)
-    * [Fehlerbehandlung](#fehlerbehandlung)
-        * [Nicht gefunden](#nicht-gefunden)
-        * [Fehler](#fehler)
-    * [Rack-Middleware](#rack-middleware)
-    * [Testen](#testen)
-    * [Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen](#sinatrabase---middleware-bibliotheken-und-modulare-anwendungen)
-        * [Modularer vs. klassischer Stil](#modularer-vs-klassischer-stil)
-        * [Eine modulare Applikation bereitstellen](#eine-modulare-applikation-bereitstellen)
-        * [Eine klassische Anwendung mit einer config.ru verwenden](#eine-klassische-anwendung-mit-einer-configru-verwenden)
-        * [Wann sollte eine config.ru-Datei verwendet werden?](#wann-sollte-eine-configru-datei-verwendet-werden)
-        * [Sinatra als Middleware nutzen](#sinatra-als-middleware-nutzen)
-        * [Dynamische Applikationserstellung](#dynamische-applikationserstellung)
-    * [Geltungsbereich und Bindung](#geltungsbereich-und-bindung)
-        * [Anwendungs- oder Klassen-Scope](#anwendungs--oder-klassen-scope)
-        * [Anfrage- oder Instanz-Scope](#anfrage--oder-instanz-scope)
-        * [Delegation-Scope](#delegation-scope)
-    * [Kommandozeile](#kommandozeile)
-      * [Multi-Threading](#multi-threading)
-    * [Systemanforderungen](#systemanforderungen)
-    * [Der neuste Stand (The Bleeding Edge)](#der-neuste-stand-the-bleeding-edge)
-        * [Mit Bundler](#mit-bundler)
-        * [Eigenes Repository](#eigenes-repository)
-        * [Gem erstellen](#gem-erstellen)
-    * [Versions-Verfahren](#versions-verfahren)
-    * [Mehr](#mehr)
-## Routen
-In Sinatra wird eine Route durch eine HTTP-Methode und ein URL-Muster definiert.
-Jeder dieser Routen wird ein Ruby-Block zugeordnet:
-```ruby
-get '/' do
-  .. zeige etwas ..
-end
-post '/' do
-  .. erstelle etwas ..
-end
-put '/' do
-  .. update etwas ..
-end
-delete '/' do
-  .. entferne etwas ..
-end
-options '/' do
-  .. zeige, was wir können ..
-end
-link '/' do
-  .. verbinde etwas ..
-end
-unlink '/' do
-  .. trenne etwas ..
-end
-```
-Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert wurden.
-Das erste Routen-Muster, das mit dem Request übereinstimmt, wird ausgeführt.
-Die Muster der Routen können benannte Parameter beinhalten, die über den
-`params`-Hash zugänglich gemacht werden:
-```ruby
-get '/hallo/:name' do
-  # passt auf "GET /hallo/foo" und "GET /hallo/bar"
-  # params['name'] ist dann 'foo' oder 'bar'
-  "Hallo #{params['name']}!"
-end
-```
-Man kann auf diese auch mit Block-Parametern zugreifen:
-```ruby
-get '/hallo/:name' do |n|
-  # n entspricht hier params['name']
-  "Hallo #{n}!"
-end
-```
-Routen-Muster können auch mit sog. Splat- oder Wildcard-Parametern über das
-`params['splat']`-Array angesprochen werden:
-```ruby
-get '/sag/*/zu/*' do
-  # passt z.B. auf /sag/hallo/zu/welt
-  params['splat'] # => ["hallo", "welt"]
-end
-get '/download/*.*' do
-  # passt auf /download/pfad/zu/datei.xml
-  params['splat'] # => ["pfad/zu/datei", "xml"]
-end
-```
-Oder mit Block-Parametern:
-```ruby
-get '/download/*.*' do |pfad, endung|
-  [pfad, endung] # => ["Pfad/zu/Datei", "xml"]
-end
-```
-Routen mit regulären Ausdrücken sind auch möglich:
-```ruby
-get /\A\/hallo\/([\w]+)\z/ do
-  "Hallo, #{params['captures'].first}!"
-end
-```
-Und auch hier können Block-Parameter genutzt werden:
-```ruby
-get %r{/hallo/([\w]+)} do |c|
-  "Hallo, #{c}!"
-end
-```
-Routen-Muster können auch mit optionalen Parametern ausgestattet werden:
-```ruby
-get '/posts/:format?' do
-  # passt auf "GET /posts/" sowie jegliche Erweiterung
-  # wie "GET /posts/json", "GET /posts/xml" etc.
-end
-```
-Routen können auch den query-Parameter verwenden:
-```ruby
-get '/posts' do
-  # matches "GET /posts?title=foo&author=bar"
-  title = params['title']
-  author = params['author']
-  # uses title and author variables; query is optional to the /posts route
-end
-```
-Anmerkung: Solange man den sog. Path Traversal Attack-Schutz nicht deaktiviert
-(siehe weiter unten), kann es sein, dass der Request-Pfad noch vor dem
-Abgleich mit den Routen modifiziert wird.
-### Bedingungen
-An Routen können eine Vielzahl von Bedingungen geknüpft werden, die erfüllt
-sein müssen, damit der Block ausgeführt wird. Möglich wäre etwa eine
-Einschränkung des User-Agents über die interne Bedingung `:agent`:
-```ruby
-get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
-  "Du verwendest Songbird Version #{params['agent'][0]}"
-end
-```
-Wird Songbird als Browser nicht verwendet, springt Sinatra zur nächsten Route:
-```ruby
-get '/foo' do
-  # passt auf andere Browser
-end
-```
-Andere mitgelieferte Bedingungen sind `:host_name` und `:provides`:
-```ruby
-get '/', :host_name => /^admin\./ do
-  "Adminbereich, Zugriff verweigert!"
-end
-get '/', :provides => 'html' do
-  haml :index
-end
-get '/', :provides => ['rss', 'atom', 'xml'] do
-  builder :feed
-end
-```
-`provides` durchsucht den Accept-Header der Anfrage
-Eigene Bedingungen können relativ einfach hinzugefügt werden:
-```ruby
-set(:wahrscheinlichkeit) { |value| condition { rand <= value } }
-get '/auto_gewinnen', :wahrscheinlichkeit => 0.1 do
-  "Du hast gewonnen!"
-end
-get '/auto_gewinnen' do
-  "Tut mir leid, verloren."
-end
-```
-Bei Bedingungen, die mehrere Werte annehmen können, sollte ein Splat verwendet
-werden:
-```ruby
-set(:auth) do |*roles|   # <- hier kommt der Splat ins Spiel
-  condition do
-    unless logged_in? && roles.any? {|role| current_user.in_role? role }
-      redirect "/login/", 303
-    end
-  end
-end
-get "/mein/account/", :auth => [:user, :admin] do
-  "Mein Account"
-end
-get "/nur/admin/", :auth => :admin do
-  "Nur Admins dürfen hier rein!"
-end
-```
-### Rückgabewerte
-Durch den Rückgabewert eines Routen-Blocks wird mindestens der Response-Body
-festgelegt, der an den HTTP-Client, bzw. die nächste Rack-Middleware,
-weitergegeben wird. Im Normalfall handelt es sich hierbei, wie in den
-vorangehenden Beispielen zu sehen war, um einen String. Es werden allerdings
-auch andere Werte akzeptiert.
-Es kann jedes gültige Objekt zurückgegeben werden, bei dem es sich entweder um
-einen Rack-Rückgabewert, einen Rack-Body oder einen HTTP-Status-Code handelt:
-*   Ein Array mit drei Elementen: `[Status (Fixnum), Headers (Hash),
-    Response-Body (antwortet auf #each)]`.
-*   Ein Array mit zwei Elementen: `[Status (Fixnum), Response-Body (antwortet
-    auf #each)]`.
-*   Ein Objekt, das auf `#each` antwortet und den an diese Methode übergebenen
-    Block nur mit Strings als Übergabewerte aufruft.
-*   Ein Fixnum, das den Status-Code festlegt.
-Damit lässt sich relativ einfach Streaming implementieren:
-```ruby
-class Stream
-  def each
-    100.times { |i| yield "#{i}\n" }
-  end
-end
-get('/') { Stream.new }
-```
-Ebenso kann die `stream`-Helfer-Methode (s.u.) verwendet werden, die Streaming
-direkt in die Route integriert.
-### Eigene Routen-Muster
-Wie oben schon beschrieben, ist Sinatra von Haus aus mit Unterstützung für
-String-Muster und Reguläre Ausdrücke zum Abgleichen von Routen ausgestattet.
-Das muss aber noch nicht alles sein, es können ohne großen Aufwand eigene
-Routen-Muster erstellt werden:
-```ruby
-class AllButPattern
-  Match = Struct.new(:captures)
-  def initialize(except)
-    @except   = except
-    @captures = Match.new([])
-  end
-  def match(str)
-    @captures unless @except === str
-  end
-end
-def all_but(pattern)
-  AllButPattern.new(pattern)
-end
-get all_but("/index") do
-  # ...
-end
-```
-Beachte, dass das obige Beispiel etwas übertrieben wirkt. Es geht auch einfacher:
-```ruby
-get // do
-  pass if request.path_info == "/index"
-  # ...
-end
-```
-Oder unter Verwendung eines negativen look ahead:
-```ruby
-get %r{^(?!/index$)} do
-  # ...
-end
-```
-## Statische Dateien
-Statische Dateien werden im `./public`-Ordner erwartet. Es ist möglich,
-einen anderen Ort zu definieren, indem man die `:public_folder`-Option setzt:
-```ruby
-set :public_folder, File.dirname(__FILE__) + '/static'
-```
-Zu beachten ist, dass der Ordnername `public` nicht Teil der URL ist. Die Datei
-`./public/css/style.css` ist unter `http://example.com/css/style.css` zu finden.
-Um den `Cache-Control`-Header mit Informationen zu versorgen, verwendet man
-die `:static_cache_control`-Einstellung (s.u.).
-## Views/Templates
-Alle Templatesprachen verwenden ihre eigene Renderingmethode, die jeweils
-einen String zurückgibt:
-```ruby
-get '/' do
-  erb :index
-end
-```
-Dieses Beispiel rendert `views/index.erb`.
-Anstelle eines Templatenamens kann man auch direkt die Templatesprache verwenden:
-```ruby
-get '/' do
-  code = "<%= Time.now %>"
-  erb code
-end
-```
-Templates nehmen ein zweite Argument an, den Options-Hash:
-```ruby
-get '/' do
-  erb :index, :layout => :post
-end
-```
-Dieses Beispiel rendert `views/index.erb` eingebettet in `views/post.erb`
-(Voreinstellung ist `views/layout.erb`, sofern es vorhanden ist.)
-Optionen, die Sinatra nicht versteht, werden an das Template weitergereicht:
-```ruby
-get '/' do
-  haml :index, :format => :html5
-end
-```
-Für alle Templates können auch Einstellungen, die für alle Routen gelten,
-festgelegt werden:
-```ruby
-set :haml, :format => :html5
-get '/' do
-  haml :index
-end
-```
-Optionen, die an die Rendermethode weitergegeben werden, überschreiben die
-Einstellungen, die mit `set` festgelegt wurden.
-Einstellungen:
-<dl>
-  <dt>locals</dt>
-  <dd>Liste von lokalen Variablen, die an das Dokument weitergegeben werden.
-    Praktisch für Partials:
-    <tt>erb "<%= foo %>", :locals => {:foo => "bar"}</tt></dd>
-  <dt>default_encoding</dt>
-  <dd>Gibt die Stringkodierung an, die verwendet werden soll. Voreingestellt
-    auf <tt>settings.default_encoding</tt>.</dd>
-  <dt>views</dt>
-  <dd>Ordner, aus dem die Templates geladen werden. Voreingestellt auf
-    <tt>settings.views</tt>.</dd>
-  <dt>layout</dt>
-  <dd>Legt fest, ob ein Layouttemplate verwendet werden soll oder nicht
-    (<tt>true</tt> oder<tt>false</tt>). Ist es ein Symbol, dann legt es fest,
-    welches Template als Layout verwendet wird:
-    <tt>erb :index, :layout => !request.xhr?</tt></dd>
-  <dt>content_type</dt>
-  <dd>Content-Typ den das Template ausgibt. Voreinstellung hängt von der
-    Templatesprache ab.</dd>
-  <dt>scope</dt>
-  <dd>Scope, in dem das Template gerendert wird. Liegt standardmäßig innerhalb
-    der App-Instanz. Wird Scope geändert, sind Instanzvariablen und
-    Helfermethoden nicht verfügbar.</dd>
-  <dt>layout_engine</dt>
-  <dd>Legt fest, welcher Renderer für das Layout verantwortlich ist. Hilfreich
-    für Sprachen, die sonst keine Templates unterstützen. Voreingestellt auf
-    den Renderer, der für das Template verwendet wird:
-    <tt>set :rdoc, :layout_engine => :erb</tt></dd>
-  <dt>layout_options</dt>
-  <dd>Besondere Einstellungen, die nur für das Rendering verwendet werden:
-    <tt>set :rdoc, :layout_options => { :views => 'views/layouts' }</tt></dd>
-</dl>
-Sinatra geht davon aus, dass die Templates sich im `./views` Verzeichnis
-befinden. Es kann jedoch ein anderer Ordner festgelegt werden:
-```ruby
-set :views, settings.root + '/templates'
-```
-Es ist zu beachten, dass immer mit Symbolen auf Templates verwiesen werden muss,
-auch dann, wenn sie sich in einem Unterordner befinden:
-```ruby
-haml :'unterverzeichnis/template'
-```
-Rendering-Methoden rendern jeden String direkt.
-### Direkte Templates
-```ruby
-get '/' do
-  haml '%div.title Hallo Welt'
-end
-```
-Hier wird der String direkt gerendert.
-### Verfügbare Templatesprachen
-Einige Sprachen haben mehrere Implementierungen. Um festzulegen, welche
-verwendet wird (und dann auch Thread-sicher ist), verwendet man am besten zu
-Beginn ein `'require'`:
-```ruby
-require 'rdiscount' # oder require 'bluecloth'
-get('/') { markdown :index }
-```
-#### Haml Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://haml.info/">haml</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.haml</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>haml :index, :format => :html5</tt></td>
-  </tr>
-</table>
-#### Erb Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://www.kuwata-lab.com/erubis/">erubis</a> oder erb
-    (Standardbibliothek von Ruby)</td>
-  </tr>
-  <tr>
-    <td>Dateierweiterungen</td>
-    <td><tt>.erb</tt>, <tt>.rhtml</tt> oder <tt>.erubis</tt> (nur Erubis)</td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>erb :index</tt></td>
-  </tr>
-</table>
-#### Builder Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/jimweirich/builder">builder</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.builder</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>builder { |xml| xml.em "Hallo" }</tt></td>
-  </tr>
-</table>
-Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
-#### Nokogiri Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://www.nokogiri.org/">nokogiri</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.nokogiri</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>nokogiri { |xml| xml.em "Hallo" }</tt></td>
-  </tr>
-</table>
-Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
-#### Sass Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://sass-lang.com/">sass</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.sass</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>sass :stylesheet, :style => :expanded</tt></td>
-  </tr>
-</table>
-#### SCSS Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://sass-lang.com/">sass</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.scss</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>scss :stylesheet, :style => :expanded</tt></td>
-  </tr>
-</table>
-#### Less Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://lesscss.org/">less</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.less</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>less :stylesheet</tt></td>
-  </tr>
-</table>
-#### Liquid Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://liquidmarkup.org/">liquid</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.liquid</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>liquid :index, :locals => { :key => 'Wert' }</tt></td>
-  </tr>
-</table>
-Da man aus dem Liquid-Template heraus keine Ruby-Methoden aufrufen kann
-(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
-denen man Variablen weitergibt.
-#### Markdown Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td>Eine der folgenden Bibliotheken:
-        <a href="https://github.com/davidfstr/rdiscount" title="RDiscount">RDiscount</a>,
-        <a href="https://github.com/vmg/redcarpet" title="RedCarpet">RedCarpet</a>,
-        <a href="http://deveiate.org/projects/BlueCloth" title="BlueCloth">BlueCloth</a>,
-        <a href="http://kramdown.gettalong.org/" title="kramdown">kramdown</a> oder
-        <a href="https://github.com/bhollis/maruku" title="maruku">maruku</a>
-    </td>
-  </tr>
-  <tr>
-    <td>Dateierweiterungen</td>
-    <td><tt>.markdown</tt>, <tt>.mkd</tt> und <tt>.md</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>markdown :index, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus den Markdown-Templates heraus keine Ruby-Methoden aufrufen und auch
-keine locals verwenden kann, wird man Markdown üblicherweise in Kombination
-mit anderen Renderern verwenden wollen:
-```ruby
-erb :overview, :locals => { :text => markdown(:einfuehrung) }
-```
-Beachte, dass man die `markdown`-Methode auch aus anderen Templates heraus
-aufrufen kann:
-```ruby
-%h1 Gruß von Haml!
-%p= markdown(:Grüße)
-```
-Da man Ruby nicht von Markdown heraus aufrufen kann, können auch Layouts nicht
-in Markdown geschrieben werden. Es ist aber möglich, einen Renderer für die
-Templates zu verwenden und einen anderen für das Layout, indem die
-`:layout_engine`-Option verwendet wird.
-#### Textile Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://redcloth.org/">RedCloth</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.textile</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>textile :index, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus dem Textile-Template heraus keine Ruby-Methoden aufrufen und auch
-keine locals verwenden kann, wird man Textile üblicherweise in Kombination mit
-anderen Renderern verwenden wollen:
-```ruby
-erb :overview, :locals => { :text => textile(:einfuehrung) }
-```
-Beachte, dass man die `textile`-Methode auch aus anderen Templates heraus
-aufrufen kann:
-```ruby
-%h1 Gruß von Haml!
-%p= textile(:Grüße)
-```
-Da man Ruby nicht von Textile heraus aufrufen kann, können auch Layouts nicht
-in Textile geschrieben werden. Es ist aber möglich, einen Renderer für die
-Templates zu verwenden und einen anderen für das Layout, indem die
-`:layout_engine`-Option verwendet wird.
-#### RDoc Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://rdoc.sourceforge.net/">rdoc</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.rdoc</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>textile :README, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus dem RDoc-Template heraus keine Ruby-Methoden aufrufen und auch
-keine locals verwenden kann, wird man RDoc üblicherweise in Kombination mit
-anderen Renderern verwenden wollen:
-```ruby
-erb :overview, :locals => { :text => rdoc(:einfuehrung) }
-```
-Beachte, dass man die `rdoc`-Methode auch aus anderen Templates heraus
-aufrufen kann:
-```ruby
-%h1 Gruß von Haml!
-%p= rdoc(:Grüße)
-```
-Da man Ruby nicht von RDoc heraus aufrufen kann, können auch Layouts nicht in
-RDoc geschrieben werden. Es ist aber möglich, einen Renderer für die Templates
-zu verwenden und einen anderen für das Layout, indem die
-`:layout_engine`-Option verwendet wird.
-#### AsciiDoc Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://asciidoctor.org/" title="Asciidoctor">Asciidoctor</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterungen</td>
-    <td><tt>.asciidoc</tt>, <tt>.adoc</tt> und <tt>.ad</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>asciidoc :README, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus dem AsciiDoc-Template heraus keine Ruby-Methoden aufrufen kann
-(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
-denen man Variablen weitergibt.
-#### Radius Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/jlong/radius">radius</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.radius</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>radius :index, :locals => { :key => 'Wert' }</tt></td>
-  </tr>
-</table>
-Da man aus dem Radius-Template heraus keine Ruby-Methoden aufrufen kann, wird
-man üblicherweise locals verwenden wollen, mit denen man Variablen weitergibt.
-#### Markaby Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://markaby.github.io/">markaby</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.mab</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>markaby { h1 "Willkommen!" }</tt></td>
-  </tr>
-</table>
-Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
-#### RABL Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/nesquena/rabl">rabl</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.rabl</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>rabl :index</tt></td>
-  </tr>
-</table>
-#### Slim Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="http://slim-lang.com/">slim</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.slim</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>slim :index</tt></td>
-  </tr>
-</table>
-#### Creole Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/minad/creole">creole</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.creole</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>creole :wiki, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus dem Creole-Template heraus keine Ruby-Methoden aufrufen und auch
-keine locals verwenden kann, wird man Creole üblicherweise in Kombination mit
-anderen Renderern verwenden wollen:
-```ruby
-erb :overview, :locals => { :text => creole(:einfuehrung) }
-```
-Beachte, dass man die `creole`-Methode auch aus anderen Templates heraus
-aufrufen kann:
-```ruby
-%h1 Gruß von Haml!
-%p= creole(:Grüße)
-```
-Da man Ruby nicht von Creole heraus aufrufen kann, können auch Layouts nicht in
-Creole geschrieben werden. Es ist aber möglich, einen Renderer für die Templates
-zu verwenden und einen anderen für das Layout, indem die `:layout_engine`-Option
-verwendet wird.
-#### MediaWiki Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/nricciar/wikicloth" title="WikiCloth">WikiCloth</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterungen</td>
-    <td><tt>.mediawiki</tt> und <tt>.mw</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>mediawiki :wiki, :layout_engine => :erb</tt></td>
-  </tr>
-</table>
-Da man aus dem Mediawiki-Template heraus keine Ruby-Methoden aufrufen und auch
-keine locals verwenden kann, wird man Mediawiki üblicherweise in Kombination mit
-anderen Renderern verwenden wollen:
-```ruby
-erb :overview, :locals => { :text => mediawiki(:introduction) }
-```
-Beachte: Man kann die `mediawiki`-Methode auch aus anderen Templates
-heraus aufrufen:
-```ruby
-%h1 Grüße von Haml!
-%p= mediawiki(:greetings)
-```
-Da man Ruby nicht von MediaWiki heraus aufrufen kann, können auch Layouts nicht
-in MediaWiki geschrieben werden. Es ist aber möglich, einen Renderer für die
-Templates zu verwenden und einen anderen für das Layout, indem die
-`:layout_engine`-Option verwendet wird.
-#### CoffeeScript Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/josh/ruby-coffee-script">coffee-script</a>
-        und eine <a href="https://github.com/sstephenson/execjs/blob/master/README.md#readme">Möglichkeit JavaScript auszuführen</a>.
-    </td>
-  </tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.coffee</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>coffee :index</tt></td>
-  </tr>
-</table>
-#### Stylus Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td>
-      <a href="https://github.com/forgecrafted/ruby-stylus" title="Ruby Stylus">
-        Stylus
-      </a> und eine Möglichkeit
-      <a href="https://github.com/sstephenson/execjs/blob/master/README.md#readme" title="ExecJS">
-        JavaScript auszuführen
-      </a>.
-    </td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.styl</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>stylus :index</tt></td>
-  </tr>
-</table>
-Um Stylus-Templates ausführen zu können, müssen `stylus` und `stylus/tilt`
-zuerst geladen werden:
-```ruby
-require 'sinatra'
-require 'stylus'
-require 'stylus/tilt'
-get '/' do
-  stylus :example
-end
-```
-#### Yajl Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/brianmario/yajl-ruby" title="yajl-ruby">yajl-ruby</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.yajl</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td>
-      <tt>
-        yajl :index,
-             :locals => { :key => 'qux' },
-             :callback => 'present',
-             :variable => 'resource'
-      </tt>
-    </td>
-  </tr>
-</table>
-Die Template-Quelle wird als Ruby-String evaluiert. Die daraus resultierende
-json Variable wird mit Hilfe von `#to_json` umgewandelt:
-```ruby
-json = { :foo => 'bar' }
-json[:baz] = key
-```
-Die `:callback` und `:variable` Optionen können mit dem gerenderten Objekt
-verwendet werden:
-```javascript
-var resource = {"foo":"bar","baz":"qux"};
-present(resource);
-```
-#### WLang Templates
-<table>
-  <tr>
-    <td>Abhängigkeit</td>
-    <td><a href="https://github.com/blambeau/wlang/">wlang</a></td>
-  </tr>
-  <tr>
-    <td>Dateierweiterung</td>
-    <td><tt>.wlang</tt></td>
-  </tr>
-  <tr>
-    <td>Beispiel</td>
-    <td><tt>wlang :index, :locals => { :key => 'value' }</tt></td>
-  </tr>
-</table>
-Ruby-Methoden in Wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
-von Wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
-Wlang und `yield` verwenden, werden aber trotzdem unterstützt.
-Rendert den eingebetteten Template-String.
-### Auf Variablen in Templates zugreifen
-Templates werden in demselben Kontext ausgeführt wie Routen. Instanzvariablen
-in Routen sind auch direkt im Template verfügbar:
-```ruby
-get '/:id' do
-  @foo = Foo.find(params['id'])
-  haml '%h1= @foo.name'
-end
-```
-Oder durch einen expliziten Hash von lokalen Variablen:
-```ruby
-get '/:id' do
-  foo = Foo.find(params['id'])
-  haml '%h1= bar.name', :locals => { :bar => foo }
-end
-```
-Dies wird typischerweise bei Verwendung von Subtemplates (partials) in anderen
-Templates eingesetzt.
-### Templates mit `yield` und verschachtelte Layouts
-Ein Layout ist üblicherweise ein Template, das ein `yield` aufruft. Ein solches
-Template kann entweder wie oben beschrieben über die `:template` Option
-verwendet werden oder mit einem Block gerendert werden:
-```ruby
-erb :post, :layout => false do
-  erb :index
-end
-```
-Dieser Code entspricht weitestgehend `erb :index, :layout => :post`.
-Blöcke an Render-Methoden weiterzugeben ist besonders bei verschachtelten
-Layouts hilfreich:
-```ruby
-erb :main_layout, :layout => false do
-  erb :admin_layout do
-    erb :user
-  end
-end
-```
-Der gleiche Effekt kann auch mit weniger Code erreicht werden:
-```ruby
-erb :admin_layout, :layout => :main_layout do
-  erb :user
-end
-```
-Zur Zeit nehmen folgende Renderer Blöcke an: `erb`, `haml`, `liquid`, `slim `
-und `wlang`.
-Das gleich gilt auch für die allgemeine `render` Methode.
-### Inline-Templates
-Templates können auch am Ende der Datei definiert werden:
-```ruby
-require 'sinatra'
-get '/' do
-  haml :index
-end
-__END__
-@@ layout
-%html
-  = yield
-@@ index
-%div.title Hallo Welt!!!!!
-```
-Anmerkung: Inline-Templates, die in der Datei definiert sind, die `require
-'sinatra'` aufruft, werden automatisch geladen. Um andere Inline-Templates in
-anderen Dateien aufzurufen, muss explizit `enable :inline_templates` verwendet
-werden.
-### Benannte Templates
-Templates können auch mit der Top-Level `template`-Methode definiert werden:
-```ruby
-template :layout do
-  "%html\n  =yield\n"
-end
-template :index do
-  '%div.title Hallo Welt!'
-end
-get '/' do
-  haml :index
-end
-```
-Wenn ein Template mit dem Namen "layout" existiert, wird es bei jedem Aufruf
-verwendet. Durch `:layout => false` kann das Ausführen verhindert werden:
-```ruby
-get '/' do
-  haml :index, :layout => !request.xhr?
-  # !request.xhr? prüft, ob es sich um einen asynchronen Request handelt.
-  # wenn nicht, dann verwende ein Layout (negiert durch !)
-end
-```
-### Dateiendungen zuordnen
-Um eine Dateiendung einer Template-Engine zuzuordnen, kann `Tilt.register`
-genutzt werden. Wenn etwa die Dateiendung `tt` für Textile-Templates genutzt
-werden soll, lässt sich dies wie folgt bewerkstelligen:
-```ruby
-Tilt.register :tt, Tilt[:textile]
-```
-### Eine eigene Template-Engine hinzufügen
-Zu allererst muss die Engine bei Tilt registriert und danach eine
-Rendering-Methode erstellt werden:
-```ruby
-Tilt.register :mtt, MeineTolleTemplateEngine
-helpers do
-  def mtt(*args) render(:mtt, *args) end
-end
-get '/' do
-  mtt :index
-end
-```
-Dieser Code rendert `./views/application.mtt`. Siehe
-[github.com/rtomayko/tilt](https://github.com/rtomayko/tilt), um mehr über
-Tilt zu erfahren.
-### Eigene Methoden zum Aufsuchen von Templates verwenden
-Um einen eigenen Mechanismus zum Aufsuchen von Templates zu
-implementieren, muss `#find_template` definiert werden:
-```ruby
-configure do
-  set :views [ './views/a', './views/b' ]
-end
-def find_template(views, name, engine, &block)
-  Array(views).each do |v|
-    super(v, name, engine, &block)
-  end
-end
-```
-## Filter
-Before-Filter werden vor jedem Request in demselben Kontext, wie danach die
-Routen, ausgeführt. So können etwa Request und Antwort geändert werden.
-Gesetzte Instanzvariablen in Filtern können in Routen und Templates verwendet
-werden:
-```ruby
-before do
-  @note = 'Hi!'
-  request.path_info = '/foo/bar/baz'
-end
-get '/foo/*' do
-  @note #=> 'Hi!'
-  params['splat'] #=> 'bar/baz'
-end
-```
-After-Filter werden nach jedem Request in demselben Kontext ausgeführt und
-können ebenfalls Request und Antwort ändern. In Before-Filtern gesetzte
-Instanzvariablen können in After-Filtern verwendet werden:
-```ruby
-after do
-  puts response.status
-end
-```
-Filter können optional auch mit einem Muster ausgestattet werden, das auf den
-Request-Pfad passen muss, damit der Filter ausgeführt wird:
-```ruby
-before '/protected/*' do
-  authenticate!
-end
-after '/create/:slug' do |slug|
-  session[:last_slug] = slug
-end
-```
-Ähnlich wie Routen können Filter auch mit weiteren Bedingungen eingeschränkt
-werden:
-```ruby
-before :agent => /Songbird/ do
-  # ...
-end
-after '/blog/*', :host_name => 'example.com' do
-  # ...
-end
-```
-## Helfer
-Durch die Top-Level `helpers`-Methode werden sogenannte Helfer-Methoden
-definiert, die in Routen und Templates verwendet werden können:
-```ruby
-helpers do
-  def bar(name)
-    "#{name}bar"
-  end
-end
-get '/:name' do
-  bar(params['name'])
-end
-```
-### Sessions verwenden
-Sessions werden verwendet, um Zustände zwischen den Requests zu speichern. Sind
-sie aktiviert, kann ein Session-Hash je Benutzer-Session verwendet werden:
-```ruby
-enable :sessions
-get '/' do
-  "value = " << session[:value].inspect
-end
-get '/:value' do
-  session[:value] = params['value']
-end
-```
-Beachte, dass `enable :sessions` alle Daten in einem Cookie speichert. Unter
-Umständen kann dies negative Effekte haben, z.B. verursachen viele Daten
-höheren, teilweise überflüssigen Traffic. Um das zu vermeiden, kann eine Rack-
-Session-Middleware verwendet werden. Dabei wird auf `enable :sessions`
-verzichtet und die Middleware wie üblich im Programm eingebunden:
-```ruby
-use Rack::Session::Pool, :expire_after => 2592000
-get '/' do
-  "value = " << session[:value].inspect
-end
-get '/:value' do
-  session[:value] = params['value']
-end
-```
-Um die Sicherheit zu erhöhen, werden Cookies, die Session-Daten führen, mit
-einem sogenannten Session-Secret signiert. Da sich dieses Geheimwort bei jedem
-Neustart der Applikation automatisch ändert, ist es sinnvoll, ein eigenes zu
-wählen, damit sich alle Instanzen der Applikation dasselbe Session-Secret
-teilen:
-```ruby
-set :session_secret, 'super_geheimes_Gegeimnis'
-```
-Zur weiteren Konfiguration kann man einen Hash mit Optionen in den `sessions`
-Einstellungen ablegen.
-```ruby
-set :sessions, :domain => 'foo.com'
-```
-Um eine Session mit anderen Apps und zwischen verschiedenen Subdomains
-von foo.com zu teilen, wird ein *.* der Domain vorangestellt:
-```ruby
-set :sessions, :domain => '.foo,com'
-```
-### Anhalten
-Zum sofortigen Stoppen eines Request in einem Filter oder einer Route:
-```ruby
-halt
-```
-Der Status kann beim Stoppen mit angegeben werden:
-```ruby
-halt 410
-```
-Oder auch den Response-Body:
-```ruby
-halt 'Hier steht der Body'
-```
-Oder beides:
-```ruby
-halt 401, 'verschwinde!'
-```
-Sogar mit Headern:
-```ruby
-halt 402, {'Content-Type' => 'text/plain'}, 'Rache'
-```
-Natürlich ist es auch möglich, ein Template mit `halt` zu verwenden:
-```ruby
-halt erb(:error)
-```
-### Weiterspringen
-Eine Route kann mittels `pass` zu der nächsten passenden Route springen:
-```ruby
-get '/raten/:wer' do
-  pass unless params['wer'] == 'Frank'
-  'Du hast mich!'
-end
-get '/raten/*' do
-  'Du hast mich nicht!'
-end
-```
-Der Block wird sofort verlassen und es wird nach der nächsten treffenden Route
-gesucht. Ein 404-Fehler wird zurückgegeben, wenn kein treffendes Routen-Muster
-gefunden wird.
-### Eine andere Route ansteuern
-Wenn nicht zu einer anderen Route gesprungen werden soll, sondern nur das
-Ergebnis einer anderen Route gefordert wird, kann `call` für einen internen
-Request verwendet werden:
-```ruby
-get '/foo' do
-  status, headers, body = call env.merge("PATH_INFO" => '/bar')
-  [status, headers, body.map(&:upcase)]
-end
-get '/bar' do
-  "bar"
-end
-```
-Beachte, dass in dem oben angegeben Beispiel die Performance erheblich erhöht
-werden kann, wenn `"bar"` in eine Helfer-Methode umgewandelt wird, auf die
-`/foo` und `/bar` zugreifen können.
-Wenn der Request innerhalb derselben Applikations-Instanz aufgerufen und keine
-Kopie der Instanz erzeugt werden soll, kann `call!` anstelle von `call`
-verwendet werden.
-### Body, Status-Code und Header setzen
-Es ist möglich und empfohlen, den Status-Code sowie den Response-Body mit einem
-Returnwert in der Route zu setzen. In manchen Situationen kann es jedoch sein,
-dass der Body an anderer Stelle während der Ausführung gesetzt werden soll.
-Dafür kann man die Helfer-Methode `body` einsetzen. Ist sie gesetzt, kann sie zu
-einem späteren Zeitpunkt aufgerufen werden:
-```ruby
-get '/foo' do
-  body "bar"
-end
-after do
-  puts body
-end
-```
-Ebenso ist es möglich, einen Block an `body` weiterzureichen, der dann vom
-Rack-Handler ausgeführt wird (lässt sich z.B. zur Umsetzung von Streaming
-einsetzen, siehe auch "Rückgabewerte").
-Vergleichbar mit `body` lassen sich auch Status-Code und Header setzen:
-```ruby
-get '/foo' do
-  status 418
-  headers \
-    "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
-    "Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
-  halt "Ich bin ein Teekesselchen"
-end
-```
-Genau wie bei `body` liest ein Aufrufen von `headers` oder `status` ohne
-Argumente den aktuellen Wert aus.
-### Response-Streams
-In manchen Situationen sollen Daten bereits an den Client zurückgeschickt
-werden, bevor ein vollständiger Response bereit steht. Manchmal will man die
-Verbindung auch erst dann beenden und Daten so lange an den Client
-zurückschicken, bis er die Verbindung abbricht. Für diese Fälle gibt es die
-`stream`-Helfer-Methode, die es einem erspart eigene Lösungen zu schreiben:
-```ruby
-get '/' do
-  stream do |out|
-    out << "Das ist ja mal wieder fanta -\n"
-    sleep 0.5
-    out << " (bitte warten…) \n"
-    sleep 1
-    out << "- stisch!\n"
-  end
-end
-```
-Damit lassen sich Streaming-APIs realisieren, sog.
-[Server Sent Events](https://w3c.github.io/eventsource/), die als Basis für
-[WebSockets](https://en.wikipedia.org/wiki/WebSocket) dienen. Ebenso können sie
-verwendet werden, um den Durchsatz zu erhöhen, wenn ein Teil der Daten von
-langsamen Ressourcen abhängig ist.
-Es ist zu beachten, dass das Verhalten beim Streaming, insbesondere die Anzahl
-nebenläufiger Anfragen, stark davon abhängt, welcher Webserver für die
-Applikation verwendet wird. Einige Server unterstützen
-Streaming nicht oder nur teilweise. Sollte der Server Streaming nicht
-unterstützen, wird ein vollständiger Response-Body zurückgeschickt, sobald der
-an `stream` weitergegebene Block abgearbeitet ist. Mit Shotgun funktioniert
-Streaming z.B. überhaupt nicht.
-Ist der optionale Parameter `keep_open` aktiviert, wird beim gestreamten Objekt
-`close` nicht aufgerufen und es ist einem überlassen dies an einem beliebigen
-späteren Zeitpunkt nachholen. Die Funktion ist jedoch nur bei Event-gesteuerten
-Serven wie Thin oder Rainbows möglich, andere Server werden trotzdem den Stream
-beenden:
-```ruby
-# Durchgehende Anfrage (long polling)
-set :server, :thin
-connections = []
-get '/subscribe' do
-  # Client-Registrierung beim Server, damit Events mitgeteilt werden können
-  stream(:keep_open) do |out|
-    connections << out
-    # tote Verbindungen entfernen
-    connections.reject!(&:closed?)
-  end
-end
-post '/:message' do
-  connections.each do |out|
-    # Den Client über eine neue Nachricht in Kenntnis setzen
-    # notify client that a new message has arrived
-    out << params['message'] << "\n"
-    # Den Client zur erneuten Verbindung auffordern
-    out.close
-  end
-  # Rückmeldung
-  "Mitteiling erhalten"
-end
-```
-### Logger
-Im Geltungsbereich eines Request stellt die `logger` Helfer-Methode eine `Logger`
-Instanz zur Verfügung:
-```ruby
-get '/' do
-  logger.info "es passiert gerade etwas"
-  # ...
-end
-```
-Der Logger übernimmt dabei automatisch alle im Rack-Handler eingestellten
-Log-Vorgaben. Ist Loggen ausgeschaltet, gibt die Methode ein Leerobjekt zurück.
-In den Routen und Filtern muss man sich also nicht weiter darum kümmern.
-Beachte, dass das Loggen standardmäßig nur für `Sinatra::Application`
-voreingestellt ist. Wird über `Sinatra::Base` vererbt, muss es erst aktiviert
-werden:
-```ruby
-class MyApp < Sinatra::Base
-  configure :production, :development  do
-    enable :logging
-  end
-end
-```
-Damit auch keine Middleware das Logging aktivieren kann, muss die `logging`
-Einstellung auf `nil` gesetzt werden. Das heißt aber auch, dass `logger` in
-diesem Fall `nil` zurückgeben wird. Üblicherweise wird das eingesetzt, wenn ein
-eigener Logger eingerichtet werden soll. Sinatra wird dann verwenden, was in
-`env['rack.logger']` eingetragen ist.
-### Mime-Types
-Wenn `send_file` oder statische Dateien verwendet werden, kann es vorkommen,
-dass Sinatra den Mime-Typ nicht kennt. Registriert wird dieser mit `mime_type`
-per Dateiendung:
-```ruby
-configure do
-  mime_type :foo, 'text/foo'
-end
-```
-Es kann aber auch der `content_type`-Helfer verwendet werden:
-```ruby
-get '/' do
-  content_type :foo
-  "foo foo foo"
-end
-```
-### URLs generieren
-Zum Generieren von URLs sollte die `url`-Helfer-Methode genutzen werden, so z.B.
-beim Einsatz von Haml:
-```ruby
-%a{:href => url('/foo')} foo
-```
-Soweit vorhanden, wird Rücksicht auf Proxys und Rack-Router genommen.
-Diese Methode ist ebenso über das Alias `to` zu erreichen (siehe Beispiel unten).
-### Browser-Umleitung
-Eine Browser-Umleitung kann mithilfe der `redirect`-Helfer-Methode erreicht
-werden:
-```ruby
-get '/foo' do
-  redirect to('/bar')
-end
-```
-Weitere Parameter werden wie Argumente der `halt`-Methode behandelt:
-```ruby
-redirect to('/bar'), 303
-redirect 'http://www.google.com/', 'Hier bist du falsch'
-```
-Ebenso leicht lässt sich ein Schritt zurück mit dem Alias `redirect back`
-erreichen:
-```ruby
-get '/foo' do
-  "<a href='/bar'>mach was</a>"
-end
-get '/bar' do
-  mach_was
-  redirect back
-end
-```
-Um Argumente an ein Redirect weiterzugeben, können sie entweder dem Query
-übergeben:
-```ruby
-redirect to('/bar?summe=42')
-```
-oder eine Session verwendet werden:
-```ruby
-enable :sessions
-get '/foo' do
-  session[:secret] = 'foo'
-  redirect to('/bar')
-end
-get '/bar' do
-  session[:secret]
-end
-```
-### Cache einsetzen
-Ein sinnvolles Einstellen von Header-Daten ist die Grundlage für ein
-ordentliches HTTP-Caching.
-Der Cache-Control-Header lässt sich ganz einfach einstellen:
-```ruby
-get '/' do
-  cache_control :public
-  "schon gecached!"
-end
-```
-Profitipp: Caching im before-Filter aktivieren
-```ruby
-before do
-  cache_control :public, :must_revalidate, :max_age => 60
-end
-```
-Bei Verwendung der `expires`-Helfermethode zum Setzen des gleichnamigen Headers,
-wird `Cache-Control` automatisch eigestellt:
-```ruby
-before do
-  expires 500, :public, :must_revalidate
-end
-```
-Um alles richtig zu machen, sollten auch `etag` oder `last_modified` verwendet
-werden. Es wird empfohlen, dass diese Helfer aufgerufen werden **bevor** die
-eigentliche Arbeit anfängt, da sie sofort eine Antwort senden, wenn der Client
-eine aktuelle Version im Cache vorhält:
-```ruby
-get '/article/:id' do
-  @article = Article.find params['id']
-  last_modified @article.updated_at
-  etag @article.sha1
-  erb :article
-end
-```
-ebenso ist es möglich einen
-[schwachen ETag](https://de.wikipedia.org/wiki/HTTP_ETag) zu verwenden:
-```ruby
-etag @article.sha1, :weak
-```
-Diese Helfer führen nicht das eigentliche Caching aus, sondern geben die dafür
-notwendigen Informationen an den Cache weiter. Für schnelle Reverse-Proxy
-Cache-Lösungen bietet sich z.B.
-[rack-cache](https://github.com/rtomayko/rack-cache) an:
-```ruby
-require "rack/cache"
-require "sinatra"
-use Rack::Cache
-get '/' do
-  cache_control :public, :max_age => 36000
-  sleep 5
-  "hello"
-end
-```
-Um den `Cache-Control`-Header mit Informationen zu versorgen, verwendet man die
-`:static_cache_control`-Einstellung (s.u.).
-Nach RFC 2616 sollte sich die Anwendung anders verhalten, wenn ein If-Match oder
-ein If-None_match Header auf `*` gesetzt wird in Abhängigkeit davon, ob die
-Resource bereits existiert. Sinatra geht davon aus, dass Ressourcen bei sicheren
-Anfragen (z.B. bei get oder Idempotenten Anfragen wie put) bereits existieren,
-wobei anderen Ressourcen (besipielsweise bei post), als neue Ressourcen
-behandelt werden. Dieses Verhalten lässt sich mit der `:new_resource` Option
-ändern:
-```ruby
-get '/create' do
-  etag '', :new_resource => true
-  Article.create
-  erb :new_article
-end
-```
-Soll das schwache ETag trotzdem verwendet werden, verwendet man die `:kind`
-Option:
-```ruby
-etag '', :new_resource => true, :kind => :weak
-```
-### Dateien versenden
-Um den Inhalt einer Datei als Response zurückzugeben, kann die
-`send_file`-Helfer-Methode verwendet werden:
-```ruby
-get '/' do
-  send_file 'foo.png'
-end
-```
-Für `send_file` stehen einige Hash-Optionen zur Verfügung:
-```ruby
-send_file 'foo.png', :type => :jpg
-```
-<dl>
-  <dt>filename</dt>
-  <dd>Dateiname als Response. Standardwert ist der eigentliche Dateiname.</dd>
-  <dt>last_modified</dt>
-  <dd>Wert für den Last-Modified-Header, Standardwert ist <tt>mtime</tt> der
-    Datei.</dd>
-  <dt>type</dt>
-  <dd>Content-Type, der verwendet werden soll. Wird, wenn nicht angegeben, von
-    der Dateiendung abgeleitet.</dd>
-  <dt>disposition</dt>
-  <dd>Verwendet für Content-Disposition. Mögliche Werte sind: <tt>nil</tt>
-    (Standard), <tt>:attachment</tt> und <tt>:inline</tt>.</dd>
-  <dt>length</dt>
-  <dd>Content-Length-Header. Standardwert ist die Dateigröße.</dd>
-</dl>
-Soweit vom Rack-Handler unterstützt, werden neben der Übertragung über den
-Ruby-Prozess auch andere Möglichkeiten genutzt. Bei Verwendung der
-`send_file`-Helfer-Methode kümmert sich Sinatra selbstständig um die
-Range-Requests.
-### Das Request-Objekt
-Auf das `request`-Objekt der eigehenden Anfrage kann vom Anfrage-Scope aus
-zugegriffen werden:
-```ruby
-# App läuft unter http://example.com/example
-get '/foo' do
-  t = %w[text/css text/html application/javascript]
-  request.accept              # ['text/html', '*/*']
-  request.accept? 'text/xml'  # true
-  request.preferred_type(t)   # 'text/html'
-  request.body                # Request-Body des Client (siehe unten)
-  request.scheme              # "http"
-  request.script_name         # "/example"
-  request.path_info           # "/foo"
-  request.port                # 80
-  request.request_method      # "GET"
-  request.query_string        # ""
-  request.content_length      # Länge des request.body
-  request.media_type          # Medientypus von request.body
-  request.host                # "example.com"
-  request.get?                # true (ähnliche Methoden für andere Verben)
-  request.form_data?          # false
-  request["irgendein_param"]  # Wert von einem Parameter; [] ist die Kurzform für den params Hash
-  request.referrer            # Der Referrer des Clients oder '/'
-  request.user_agent          # User-Agent (verwendet in der :agent Bedingung)
-  request.cookies             # Hash des Browser-Cookies
-  request.xhr?                # Ist das hier ein Ajax-Request?
-  request.url                 # "http://example.com/example/foo"
-  request.path                # "/example/foo"
-  request.ip                  # IP-Adresse des Clients
-  request.secure?             # false (true wenn SSL)
-  request.forwarded?          # true (Wenn es hinter einem Reverse-Proxy verwendet wird)
-  request.env                 # vollständiger env-Hash von Rack übergeben
-end
-```
-Manche Optionen, wie etwa `script_name` oder `path_info`, sind auch
-schreibbar:
-```ruby
-before { request.path_info = "/" }
-get "/" do
-  "Alle Anfragen kommen hier an!"
-end
-```
-Der `request.body` ist ein IO- oder StringIO-Objekt:
-```ruby
-post "/api" do
-  request.body.rewind # falls schon jemand davon gelesen hat
-  daten = JSON.parse request.body.read
-  "Hallo #{daten['name']}!"
-end
-```
-### Anhänge
-Damit der Browser erkennt, dass ein Response gespeichert und nicht im Browser
-angezeigt werden soll, kann der `attachment`-Helfer verwendet werden:
-```ruby
-get '/' do
-  attachment
-  "Speichern!"
-end
-```
-Ebenso kann eine Dateiname als Parameter hinzugefügt werden:
-```ruby
-get '/' do
-  attachment "info.txt"
-  "Speichern!"
-end
-```
-### Umgang mit Datum und Zeit
-Sinatra bietet eine `time_for`-Helfer-Methode, die aus einem gegebenen Wert ein
-Time-Objekt generiert. Ebenso kann sie nach `DateTime`, `Date` und ähnliche
-Klassen konvertieren:
-```ruby
-get '/' do
-  pass if Time.now > time_for('Dec 23, 2012')
-  "noch Zeit"
-end
-```
-Diese Methode wird intern für +expires, `last_modiefied` und ihresgleichen
-verwendet. Mit ein paar Handgriffen lässt sich diese Methode also in ihrem
-Verhalten erweitern, indem man `time_for` in der eigenen Applikation
-überschreibt:
-```ruby
-helpers do
-  def time_for(value)
-    case value
-    when :yesterday then Time.now - 24*60*60
-    when :tomorrow  then Time.now + 24*60*60
-    else super
-    end
-  end
-end
-get '/' do
-  last_modified :yesterday
-  expires :tomorrow
-  "Hallo"
-end
-```
-### Nachschlagen von Template-Dateien
-Die `find_template`-Helfer-Methode wird genutzt, um Template-Dateien zum Rendern
-aufzufinden:
-```ruby
-find_template settings.views, 'foo', Tilt[:haml] do |file|
-  puts "könnte diese hier sein: #{file}"
-end
-```
-Das ist zwar nicht wirklich brauchbar, aber wenn man sie überschreibt, kann sie
-nützlich werden, um eigene Nachschlage-Mechanismen einzubauen. Zum Beispiel
-dann, wenn mehr als nur ein view-Verzeichnis verwendet werden soll:
-```ruby
-set :views, ['views', 'templates']
-helpers do
-  def find_template(views, name, engine, &block)
-    Array(views).each { |v| super(v, name, engine, &block) }
-  end
-end
-```
-Ein anderes Beispiel wäre, verschiedene Vereichnisse für verschiedene Engines
-zu verwenden:
-```ruby
-set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views'
-helpers do
-  def find_template(views, name, engine, &block)
-    _, folder = views.detect { |k,v| engine == Tilt[k] }
-    folder ||= views[:default]
-    super(folder, name, engine, &block)
-  end
-end
-```
-Ebensogut könnte eine Extension aber auch geschrieben und mit anderen geteilt
-werden!
-Beachte, dass `find_template` nicht prüft, ob eine Datei tatsächlich existiert.
-Es wird lediglich der angegebene Block aufgerufen und nach allen möglichen
-Pfaden gesucht. Das ergibt kein Performance-Problem, da `render` `block`
-verwendet, sobald eine Datei gefunden wurde. Ebenso werden Template-Pfade samt
-Inhalt gecached, solange nicht im Entwicklungsmodus gearbeitet wird. Das sollte
-im Hinterkopf behalten werden, wenn irgendwelche verrückten Methoden
-zusammenbastelt werden.
-### Konfiguration
-Wird einmal beim Starten in jedweder Umgebung ausgeführt:
-```ruby
-configure do
-  # setze eine Option
-  set :option, 'wert'
-  # setze mehrere Optionen
-  set :a => 1, :b => 2
-  # das gleiche wie `set :option, true`
-  enable :option
-  # das gleiche wie `set :option, false`
-  disable :option
-  # dynamische Einstellungen mit Blöcken
-  set(:css_dir) { File.join(views, 'css') }
-end
-```
-Läuft nur, wenn die Umgebung (RACK_ENV-Umgebungsvariable) auf `:production`
-gesetzt ist:
-```ruby
-configure :production do
-  ...
-end
-```
-Läuft nur, wenn die Umgebung auf `:production` oder auf `:test` gesetzt ist:
-```ruby
-configure :production, :test do
-  ...
-end
-```
-Diese Einstellungen sind über `settings` erreichbar:
-```ruby
-configure do
-  set :foo, 'bar'
-end
-get '/' do
-  settings.foo? # => true
-  settings.foo  # => 'bar'
-  ...
-end
-```
-#### Einstellung des Angriffsschutzes
-Sinatra verwendet
-[Rack::Protection](https://github.com/sinatra/rack-protection#readme), um die
-Anwendung vor häufig vorkommenden Angriffen zu schützen. Diese Voreinstellung
-lässt sich selbstverständlich deaktivieren, der damit verbundene
-Geschwindigkeitszuwachs steht aber in keinem Verhätnis zu den möglichen
-Risiken.
-```ruby
-disable :protection
-```
-Um einen bestimmten Schutzmechanismus zu deaktivieren, fügt man `protection`
-einen Hash mit Optionen hinzu:
-```ruby
-set :protection, :except => :path_traversal
-```
-Neben Strings akzeptiert `:except` auch Arrays, um gleich mehrere
-Schutzmechanismen zu deaktivieren:
-```ruby
-set :protection, :except => [:path_traversal, :session_hijacking]
-```
-#### Mögliche Einstellungen
-<dl>
-  <dt>absolute_redirects</dt>
-  <dd>Wenn ausgeschaltet, wird Sinatra relative Redirects zulassen. Jedoch ist
-  Sinatra dann nicht mehr mit RFC 2616 (HTTP 1.1) konform, das nur absolute
-  Redirects zulässt. Sollte eingeschaltet werden, wenn die Applikation hinter
-  einem Reverse-Proxy liegt, der nicht ordentlich eingerichtet ist. Beachte,
-  dass die <tt>url</tt>-Helfer-Methode nach wie vor absolute URLs erstellen
-  wird, es sei denn, es wird als zweiter Parameter <tt>false</tt> angegeben.
-  Standardmäßig nicht aktiviert.</dd>
-  <dt>add_charset</dt>
-  <dd>Mime-Types werden hier automatisch der Helfer-Methode
-  <tt>content_type</tt> zugeordnet. Es empfielt sich, Werte hinzuzufügen statt
-  sie zu überschreiben: <tt>settings.add_charset << "application/foobar"</tt>
-  </dd>
-  <dt>app_file</dt>
-  <dd>Pfad zur Hauptdatei der Applikation. Wird verwendet, um das Wurzel-,
-  Inline-, View- und öffentliche Verzeichnis des Projekts festzustellen.</dd>
-  <dt>bind</dt>
-  <dd>IP-Address, an die gebunden wird (Standardwert: <tt>0.0.0.0</tt>
-  <em>oder</em> <tt>localhost</tt>). Wird  nur für den eingebauten Server
-  verwendet.</dd>
-  <dt>default_encoding</dt>
-  <dd>Das Encoding, falls keines angegeben wurde. Standardwert ist
-  <tt>"utf-8"</tt>.</dd>
-  <dt>dump_errors</dt>
-  <dd>Fehler im Log anzeigen.</dd>
-  <dt>environment</dt>
-  <dd>Momentane Umgebung. Standardmäßig auf <tt>content_type</tt> oder
-  <tt>"development"</tt> eingestellt, soweit ersteres nicht vorhanden.</dd>
-  <dt>logging</dt>
-  <dd>Den Logger verwenden.</dd>
-  <dt>lock</dt>
-  <dd>Jeder Request wird gelocked. Es kann nur ein Request pro Ruby-Prozess
-  gleichzeitig verarbeitet werden. Eingeschaltet, wenn die Applikation
-  threadsicher ist. Standardmäßig nicht aktiviert.</dd>
-  <dt>method_override</dt>
-  <dd>Verwende <tt>_method</tt>, um put/delete-Formulardaten in Browsern zu
-  verwenden, die dies normalerweise nicht unterstützen.</dd>
-  <dt>port</dt>
-  <dd>Port für die Applikation. Wird nur im internen Server verwendet.</dd>
-  <dt>prefixed_redirects</dt>
-  <dd>Entscheidet, ob <tt>request.script_name</tt> in Redirects eingefügt wird
-  oder nicht, wenn kein absoluter Pfad angegeben ist. Auf diese Weise verhält
-  sich <tt>redirect '/foo'</tt> so, als wäre es ein <tt>redirect
-  to('/foo')</tt>. Standardmäßig nicht aktiviert.</dd>
-  <dt>protection</dt>
-  <dd>Legt fest, ob der Schutzmechanismus für häufig Vorkommende Webangriffe
-  auf Webapplikationen aktiviert wird oder nicht. Weitere Informationen im
-  vorhergehenden Abschnitt.</dd>
-  <dt>public_folder</dt>
-  <dd>Das öffentliche Verzeichnis, aus dem Daten zur Verfügung gestellt werden
-  können. Wird nur dann verwendet, wenn statische Daten zur Verfügung gestellt
-  werden können (s.u. <tt>static</tt> Option). Leitet sich von der
-  <tt>app_file</tt> Einstellung ab, wenn nicht gesetzt.</dd>
-  <dt>public_dir</dt>
-  <dd>Alias für <tt>public_folder</tt>, s.o.</dd>
-  <dt>reload_templates</dt>
-  <dd>Im development-Modus aktiviert.</dd>
-  <dt>root</dt>
-  <dd>Wurzelverzeichnis des Projekts. Leitet sich von der <tt>app_file</tt>
-  Einstellung ab, wenn nicht gesetzt.</dd>
-  <dt>raise_errors</dt>
-  <dd>Einen Ausnahmezustand aufrufen. Beendet die Applikation. Ist automatisch
-  aktiviert, wenn die Umgebung auf <tt>"test"</tt> eingestellt ist. Ansonsten
-  ist diese Option deaktiviert.</dd>
-  <dt>run</dt>
-  <dd>Wenn aktiviert, wird Sinatra versuchen, den Webserver zu starten. Nicht
-  verwenden, wenn Rackup oder anderes verwendet werden soll.</dd>
-  <dt>running</dt>
-  <dd>Läuft der eingebaute Server? Diese Einstellung nicht ändern!</dd>
-  <dt>server</dt>
-  <dd>Server oder Liste von Servern, die als eingebaute Server zur Verfügung
-  stehen. Die Reihenfolge gibt die Priorität vor, die Voreinstellung hängt von
-  der verwendenten Ruby Implementierung ab.</dd>
-  <dt>sessions</dt>
-  <dd>Sessions auf Cookiebasis mittels
-  <tt>Rack::Session::Cookie</tt>aktivieren. Für weitere Infos bitte in der
-  Sektion ‘Sessions verwenden’ nachschauen.</dd>
-  <dt>show_exceptions</dt>
-  <dd>Bei Fehlern einen Stacktrace im Browseranzeigen. Ist automatisch
-  aktiviert, wenn die Umgebung auf <tt>"development"</tt> eingestellt ist.
-  Ansonsten ist diese Option deaktiviert. Kann auch auf <tt>:after_handler</tt>
-  gestellt werden, um eine anwendungsspezifische Fehlerbehandlung auszulösen,
-  bevor der Fehlerverlauf im Browser angezeigt wird.</dd>
-  <dt>static</dt>
-  <dd>Entscheidet, ob Sinatra statische Dateien zur Verfügung stellen soll oder
-  nicht. Sollte nicht aktiviert werden, wenn ein Server verwendet wird, der
-  dies auch selbstständig erledigen kann. Deaktivieren wird die Performance
-  erhöhen. Standardmäßig aktiviert.</dd>
-  <dt>static_cache_control</dt>
-  <dd>Wenn Sinatra statische Daten zur Verfügung stellt, können mit dieser
-  Einstellung die <tt>Cache-Control</tt> Header zu den Responses hinzugefügt
-  werden. Die Einstellung verwendet dazu die <tt>cache_control</tt>
-  Helfer-Methode. Standardmäßig deaktiviert. Ein Array wird verwendet, um
-  mehrere Werte gleichzeitig zu übergeben: <tt>set :static_cache_control,
-  [:public, :max_age => 300]</tt></dd>
-  <dt>threaded</dt>
-  <dd>Wird es auf <tt>true</tt> gesetzt, wird Thin aufgefordert
-  <tt>EventMachine.defer</tt> zur Verarbeitung des Requests einzusetzen.</dd>
-  <dt>traps</dt>
-  <dd>Einstellung, Sinatra System signalen umgehen soll.</dd>
-  <dt>views</dt>
-  <dd>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
-  ab, wenn nicht gesetzt.</dd>
-  <dt>x_cascade</dt>
-  <dd>Einstellung, ob der X-Cascade Header bei fehlender Route gesetzt wird oder
-  nicht. Standardeinstellung ist <tt>true</tt>.</dd>
-</dl>
-## Umgebungen
-Es gibt drei voreingestellte Umgebungen in Sinatra: `"development"`,
-`"production"` und `"test"`. Umgebungen können über die `RACK_ENV`
-Umgebungsvariable gesetzt werden. Die Standardeinstellung ist `"development"`.
-In diesem Modus werden alle Templates zwischen Requests neu geladen. Dazu gibt
-es besondere Fehlerseiten für 404 Stati und Fehlermeldungen. In `"production"`
-und `"test"` werden Templates automatisch gecached.
-Um die Anwendung in einer anderen Umgebung auszuführen kann man die `-e`
-Option verwenden:
-```shell
-ruby my_app.rb -e [ENVIRONMENT]
-```
-In der Anwendung kann man die die Methoden  `development?`, `test?` und
-`production?` verwenden, um die aktuelle Umgebung zu erfahren.
-## Fehlerbehandlung
-Error-Handler laufen in demselben Kontext wie Routen und Filter, was bedeutet,
-dass alle Goodies wie `haml`, `erb`, `halt`, etc. verwendet werden können.
-### Nicht gefunden
-Wenn eine `Sinatra::NotFound`-Exception geworfen wird oder der Statuscode 404
-ist, wird der `not_found`-Handler ausgeführt:
-```ruby
-not_found do
-  'Seite kann nirgendwo gefunden werden.'
-end
-```
-### Fehler
-Der `error`-Handler wird immer ausgeführt, wenn eine Exception in einem
-Routen-Block oder in einem Filter geworfen wurde. In der
-`development`-Umgebung wird es nur dann funktionieren, wenn die
-`:show_exceptions`-Option auf `:after_handler` eingestellt wurde:
-```ruby
-set :show_exceptions, :after_handler
-```
-Die Exception kann über die `sinatra.error`-Rack-Variable angesprochen werden:
-```ruby
-error do
-  'Entschuldige, es gab einen hässlichen Fehler - ' + env['sinatra.error'].message
-end
-```
-Benutzerdefinierte Fehler:
-```ruby
-error MeinFehler do
-  'Au weia, ' + env['sinatra.error'].message
-end
-```
-Dann, wenn das passiert:
-```ruby
-get '/' do
-  raise MeinFehler, 'etwas Schlimmes ist passiert'
-end
-```
-bekommt man dieses:
-```shell
-Au weia, etwas Schlimmes ist passiert
-```
-Alternativ kann ein Error-Handler auch für einen Status-Code definiert werden:
-```ruby
-error 403 do
-  'Zugriff verboten'
-end
-get '/geheim' do
-  403
-end
-```
-Oder ein Status-Code-Bereich:
-```ruby
-error 400..510 do
-  'Hallo?'
-end
-```
-Sinatra setzt verschiedene `not_found`- und `error`-Handler in der
-Development-Umgebung ein, um hilfreiche Debugging Informationen und Stack Traces
-anzuzeigen.
-## Rack-Middleware
-Sinatra baut auf [Rack](http://rack.github.io/), einem minimalistischen
-Standard-Interface für Ruby-Webframeworks. Eines der interessantesten Features
-für Entwickler ist der Support von Middlewares, die zwischen den Server und
-die Anwendung geschaltet werden und so HTTP-Request und/oder Antwort
-überwachen und/oder manipulieren können.
-Sinatra macht das Erstellen von Middleware-Verkettungen mit der
-Top-Level-Methode `use` zu einem Kinderspiel:
-```ruby
-require 'sinatra'
-require 'meine_middleware'
-use Rack::Lint
-use MeineMiddleware
-get '/hallo' do
-  'Hallo Welt'
-end
-```
-Die Semantik von `use` entspricht der gleichnamigen Methode der
-[Rack::Builder](http://www.rubydoc.info/github/rack/rack/master/Rack/Builder)-DSL
-(meist verwendet in Rackup-Dateien). Ein Beispiel dafür ist, dass die
-`use`-Methode mehrere/verschiedene Argumente und auch Blöcke entgegennimmt:
-```ruby
-use Rack::Auth::Basic do |username, password|
-  username == 'admin' && password == 'geheim'
-end
-```
-Rack bietet eine Vielzahl von Standard-Middlewares für Logging, Debugging,
-URL-Routing, Authentifizierung und Session-Verarbeitung. Sinatra verwendet
-viele von diesen Komponenten automatisch, abhängig von der Konfiguration. So
-muss `use` häufig nicht explizit verwendet werden.
-Hilfreiche Middleware gibt es z.B. hier:
-[rack](https://github.com/rack/rack/tree/master/lib/rack),
-[rack-contrib](https://github.com/rack/rack-contrib#readme),
-oder im [Rack wiki](https://github.com/rack/rack/wiki/List-of-Middleware).
-## Testen
-Sinatra-Tests können mit jedem auf Rack aufbauendem Test-Framework geschrieben
-werden. [Rack::Test](http://www.rubydoc.info/github/brynary/rack-test/master/frames)
-wird empfohlen:
-```ruby
-require 'my_sinatra_app'
-require 'minitest/autorun'
-require 'rack/test'
-class MyAppTest < Minitest::Test
-  include Rack::Test::Methods
-  def app
-    Sinatra::Application
-  end
-  def test_my_default
-    get '/'
-    assert_equal 'Hallo Welt!', last_response.body
-  end
-  def test_with_params
-    get '/meet', :name => 'Frank'
-    assert_equal 'Hallo Frank!', last_response.body
-  end
-  def test_with_rack_env
-    get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
-    assert_equal "Du verwendest Songbird!", last_response.body
-  end
-end
-```
-Hinweis: Wird Sinatra modular verwendet, muss <tt>Sinatra::Application</tt> mit
-dem Namen der Applikations-Klasse ersetzt werden.
-## Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen
-Das Definieren einer Top-Level-Anwendung funktioniert gut für
-Mikro-Anwendungen, hat aber Nachteile, wenn wiederverwendbare Komponenten wie
-Middleware, Rails Metal, einfache Bibliotheken mit Server-Komponenten oder
-auch Sinatra-Erweiterungen geschrieben werden sollen.
-Das Top-Level geht von einer Konfiguration für eine Mikro-Anwendung aus (wie
-sie z.B. bei einer einzelnen Anwendungsdatei, `./public` und `./views` Ordner,
-Logging, Exception-Detail-Seite, usw.). Genau hier kommt `Sinatra::Base` ins
-Spiel:
-```ruby
-require 'sinatra/base'
-class MyApp < Sinatra::Base
-  set :sessions, true
-  set :foo, 'bar'
-  get '/' do
-    'Hallo Welt!'
-  end
-end
-```
-Die MyApp-Klasse ist eine unabhängige Rack-Komponente, die als Middleware,
-Endpunkt oder via Rails Metal verwendet werden kann. Verwendet wird sie durch
-`use` oder `run` von einer Rackup-`config.ru`-Datei oder als Server-Komponente
-einer Bibliothek:
-```ruby
-MyApp.run! :host => 'localhost', :port => 9090
-```
-Die Methoden der `Sinatra::Base`-Subklasse sind genau dieselben wie die der
-Top-Level-DSL. Die meisten Top-Level-Anwendungen können mit nur zwei
-Veränderungen zu `Sinatra::Base` konvertiert werden:
-*   Die Datei sollte `require 'sinatra/base'` anstelle von `require
-    'sinatra/base'` aufrufen, ansonsten werden alle von Sinatras DSL-Methoden
-    in den Top-Level-Namespace importiert.
-*   Alle Routen, Error-Handler, Filter und Optionen der Applikation müssen in
-    einer Subklasse von `Sinatra::Base` definiert werden.
-`Sinatra::Base` ist ein unbeschriebenes Blatt. Die meisten Optionen sind per
-Standard deaktiviert. Das betrifft auch den eingebauten Server. Siehe
-[Optionen und Konfiguration](http://www.sinatrarb.com/configuration.html) für
-Details über mögliche Optionen.
-Damit eine App sich ähnlich wie eine klassische App verhält, kann man
-auch eine Subclass von `Sinatra::Application` erstellen:
-```ruby
-require 'sinatra/base'
-class MyApp < Sinatra::Application
-  get '/' do
-    'Hello world!'
-  end
-end
-```
-### Modularer vs. klassischer Stil
-Entgegen häufiger Meinungen gibt es nichts gegen den klassischen Stil
-einzuwenden. Solange es die Applikation nicht beeinträchtigt, besteht kein
-Grund, eine modulare Applikation zu erstellen.
-Der größte Nachteil der klassischen Sinatra Anwendung gegenüber einer
-modularen ist die Einschränkung auf eine Sinatra Anwendung pro Ruby-Prozess.
-Sollen mehrere zum Einsatz kommen, muss auf den modularen Stil umgestiegen
-werden. Dabei ist es kein Problem klassische und modulare Anwendungen
-miteinander zu vermischen.
-Bei einem Umstieg, sollten einige Unterschiede in den Einstellungen beachtet
-werden:
-<table>
-  <tr>
-    <th>Szenario</th>
-    <th>Classic</th>
-    <th>Modular</th>
-    <th>Modular</th>
-  </tr>
-  <tr>
-    <td>app_file</td>
-    <td>Sinatra ladende Datei</td>
-    <td>Sinatra::Base subklassierende Datei</td>
-    <td>Sinatra::Application subklassierende Datei</td>
-  </tr>
-  <tr>
-    <td>run</td>
-    <td>$0 == app_file</td>
-    <td>false</td>
-    <td>false</td>
-  </tr>
-  <tr>
-    <td>logging</td>
-    <td>true</td>
-    <td>false</td>
-    <td>true</td>
-  </tr>
-  <tr>
-    <td>method_override</td>
-    <td>true</td>
-    <td>false</td>
-    <td>true</td>
-  </tr>
-  <tr>
-    <td>inline_templates</td>
-    <td>true</td>
-    <td>false</td>
-    <td>true</td>
-  </tr>
-  <tr>
-    <td>static</td>
-    <td>true</td>
-    <td>File.exist?(public_folder)</td>
-    <td>true</td>
-  </tr>
-</table>
-### Eine modulare Applikation bereitstellen
-Es gibt zwei übliche Wege, eine modulare Anwendung zu starten. Zum einen über
-`run!`:
-```ruby
-# mein_app.rb
-require 'sinatra/base'
-class MeinApp < Sinatra::Base
-  # ... Anwendungscode hierhin ...
-  # starte den Server, wenn die Ruby-Datei direkt ausgeführt wird
-  run! if app_file == $0
-end
-```
-Starte mit:
-```shell
-ruby mein_app.rb
-```
-Oder über eine `config.ru`-Datei, die es erlaubt, einen beliebigen
-Rack-Handler zu verwenden:
-```ruby
-# config.ru (mit rackup starten)
-require './mein_app'
-run MeineApp
-```
-Starte:
-```shell
-rackup -p 4567
-```
-### Eine klassische Anwendung mit einer config.ru verwenden
-Schreibe eine Anwendungsdatei:
-```ruby
-# app.rb
-require 'sinatra'
-get '/' do
-  'Hallo Welt!'
-end
-```
-sowie eine dazugehörige `config.ru`-Datei:
-```ruby
-require './app'
-run Sinatra::Application
-```
-### Wann sollte eine config.ru-Datei verwendet werden?
-Anzeichen dafür, dass eine `config.ru`-Datei gebraucht wird:
-*   Es soll ein anderer Rack-Handler verwendet werden (Passenger, Unicorn,
-    Heroku, ...).
-*   Es gibt mehr als nur eine Subklasse von `Sinatra::Base`.
-*   Sinatra soll als Middleware verwendet werden, nicht als Endpunkt.
-**Es gibt keinen Grund, eine `config.ru`-Datei zu verwenden, nur weil eine
-Anwendung im modularen Stil betrieben werden soll. Ebenso wird keine Anwendung
-mit modularem Stil benötigt, um eine `config.ru`-Datei zu verwenden.**
-### Sinatra als Middleware nutzen
-Es ist nicht nur möglich, andere Rack-Middleware mit Sinatra zu nutzen, es
-kann außerdem jede Sinatra-Anwendung selbst als Middleware vor jeden
-beliebigen Rack-Endpunkt gehangen werden. Bei diesem Endpunkt muss es sich
-nicht um eine andere Sinatra-Anwendung handeln, es kann jede andere
-Rack-Anwendung sein (Rails/Ramaze/Camping/...):
-```ruby
-require 'sinatra/base'
-class LoginScreen < Sinatra::Base
-  enable :sessions
-  get('/login') { haml :login }
-  post('/login') do
-    if params['name'] == 'admin' && params['password'] == 'admin'
-      session['user_name'] = params['name']
-    else
-      redirect '/login'
-    end
-  end
-end
-class MyApp < Sinatra::Base
-  # Middleware wird vor Filtern ausgeführt
-  use LoginScreen
-  before do
-    unless session['user_name']
-      halt "Zugriff verweigert, bitte <a href='/login'>einloggen</a>."
-    end
-  end
-  get('/') { "Hallo #{session['user_name']}." }
-end
-```
-### Dynamische Applikationserstellung
-Manche Situationen erfordern die Erstellung neuer Applikationen zur Laufzeit,
-ohne dass sie einer Konstanten zugeordnet werden. Dies lässt sich mit
-`Sinatra.new` erreichen:
-```ruby
-require 'sinatra/base'
-my_app = Sinatra.new { get('/') { "hallo" } }
-my_app.run!
-```
-Die Applikation kann mit Hilfe eines optionalen Parameters erstellt werden:
-```ruby
-# config.ru
-require 'sinatra/base'
-controller = Sinatra.new do
-  enable :logging
-  helpers MyHelpers
-end
-map('/a') do
-  run Sinatra.new(controller) { get('/') { 'a' } }
-end
-map('/b') do
-  run Sinatra.new(controller) { get('/') { 'b' } }
-end
-```
-Das ist besonders dann interessant, wenn Sinatra-Erweiterungen getestet werden
-oder Sinatra in einer Bibliothek Verwendung findet.
-Ebenso lassen sich damit hervorragend Sinatra-Middlewares erstellen:
-```ruby
-require 'sinatra/base'
-use Sinatra do
-  get('/') { ... }
-end
-run RailsProject::Application
-```
-## Geltungsbereich und Bindung
-Der Geltungsbereich (Scope) legt fest, welche Methoden und Variablen zur
-Verfügung stehen.
-### Anwendungs- oder Klassen-Scope
-Jede Sinatra-Anwendung entspricht einer `Sinatra::Base`-Subklasse. Falls die
-Top- Level-DSL verwendet wird (`require 'sinatra'`), handelt es sich um
-`Sinatra::Application`, andernfalls ist es jene Subklasse, die explizit
-angelegt wurde. Auf Klassenebene stehen Methoden wie `get` oder `before` zur
-Verfügung, es gibt aber keinen Zugriff auf das `request`-Object oder die
-`session`, da nur eine einzige Klasse für alle eingehenden Anfragen genutzt
-wird.
-Optionen, die via `set` gesetzt werden, sind Methoden auf Klassenebene:
-```ruby
-class MyApp < Sinatra::Base
-  # Hey, ich bin im Anwendungsscope!
-  set :foo, 42
-  foo # => 42
-  get '/foo' do
-    # Hey, ich bin nicht mehr im Anwendungs-Scope!
-  end
-end
-```
-Im Anwendungs-Scope befindet man sich:
-*   In der Anwendungs-Klasse.
-*   In Methoden, die von Erweiterungen definiert werden.
-*   Im Block, der an `helpers` übergeben wird.
-*   In Procs und Blöcken, die an `set` übergeben werden.
-*   Der an `Sinatra.new` übergebene Block
-Auf das Scope-Objekt (die Klasse) kann wie folgt zugegriffen werden:
-*   Über das Objekt, das an den `configure`-Block übergeben wird (`configure {
-    |c| ... }`).
-*   `settings` aus den anderen Scopes heraus.
-### Anfrage- oder Instanz-Scope
-Für jede eingehende Anfrage wird eine neue Instanz der Anwendungs-Klasse
-erstellt und alle Handler in diesem Scope ausgeführt. Aus diesem Scope heraus
-kann auf `request` oder `session` zugegriffen und Methoden wie `erb` oder
-`haml` aufgerufen werden. Außerdem kann mit der `settings`-Method auf den
-Anwendungs-Scope zugegriffen werden:
-```ruby
-class MyApp < Sinatra::Base
-  # Hey, ich bin im Anwendungs-Scope!
-  get '/neue_route/:name' do
-    # Anfrage-Scope für '/neue_route/:name'
-    @value = 42
-    settings.get "/#{params['name']}" do
-      # Anfrage-Scope für "/#{params['name']}"
-      @value # => nil (nicht dieselbe Anfrage)
-    end
-    "Route definiert!"
-  end
-end
-```
-Im Anfrage-Scope befindet man sich:
-*   In get, head, post, put, delete, options, patch, link und unlink Blöcken
-*   In before und after Filtern
-*   In Helfer-Methoden
-*   In Templates
-### Delegation-Scope
-Vom Delegation-Scope aus werden Methoden einfach an den Klassen-Scope
-weitergeleitet. Dieser verhält sich jedoch nicht 100%ig wie der Klassen-Scope,
-da man nicht die Bindung der Klasse besitzt: Nur Methoden, die explizit als
-delegierbar markiert wurden, stehen hier zur Verfügung und es kann nicht auf
-die Variablen des Klassenscopes zugegriffen werden (mit anderen Worten: es
-gibt ein anderes `self`). Weitere Delegationen können mit
-`Sinatra::Delegator.delegate :methoden_name` hinzugefügt werden.
-Im Delegation-Scop befindet man sich:
-*   Im Top-Level, wenn `require 'sinatra'` aufgerufen wurde.
-*   In einem Objekt, das mit dem `Sinatra::Delegator`-Mixin erweitert wurde.
-Schau am besten im Code nach: Hier ist [Sinatra::Delegator
-mixin](http://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1064
-) definiert und wird in den [globalen Namespace
-eingebunden](http://github.com/sinatra/sinatra/blob/master/lib/sinatra/main.rb
-## Kommandozeile
-Sinatra-Anwendungen können direkt von der Kommandozeile aus gestartet werden:
-```shell
-ruby myapp.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-h HOST] [-s HANDLER]
-```
-Die Optionen sind:
-```
--h # Hilfe
--p # Port setzen (Standard ist 4567)
--h # Host setzen (Standard ist 0.0.0.0)
--e # Umgebung setzen (Standard ist development)
--s # Rack-Server/Handler setzen (Standard ist thin)
--x # Mutex-Lock einschalten (Standard ist off)
-```
-### Multi-threading
-_Paraphrasiert von [dieser Antwort auf StackOverflow][so-answer] von Konstantin_
-Sinatra erlegt kein Nebenläufigkeitsmodell auf, sondern überlässt dies dem
-selbst gewählten Rack-Proxy (Server), so wie Thin, Puma oder WEBrick.
-Sinatra selbst ist Thread-sicher, somit ist es kein Problem wenn der
-Rack-Proxy ein anderes Threading-Modell für Nebenläufigkeit benutzt.
-Das heißt, dass wenn der Server gestartet wird, dass man die korrekte
-Aufrufsmethode benutzen sollte für den jeweiligen Rack-Proxy.
-Das folgende Beispiel ist eine Veranschaulichung eines mehrprozessigen
-Thin Servers:
-``` ruby
-# app.rb
-require 'sinatra/base'
-class App < Sinatra::Base
-  get '/' do
-    "Hello, World"
-  end
-end
-App.run!
-```
-Um den Server zu starten, führt man das folgende Kommando aus:
-``` shell
-thin --threaded start
-```
-[so-answer]: http://stackoverflow.com/questions/6278817/is-sinatra-multi-threaded/6282999#6282999)
-## Systemanforderungen
-Die folgenden Versionen werden offiziell unterstützt:
-<dl>
-<dt>Ruby 1.8.7</dt>
-<dd>1.8.7 wird vollständig unterstützt, ein Wechsel zu JRuby oder Rubinius wird
-aber empfohlen. Ruby 1.8.7 wird noch bis Sinatra 2.0 unterstützt werden. Frühere
-Versionen von Ruby sind nicht kompatibel mit Sinatra.</dd>
-<dt>Ruby 1.9.2</dt>
-<dd>1.9.2 wird mindestens bis Sinatra 1.5 voll unterstützt. Version 1.9.2p0
-sollte nicht verwendet werden, da unter Sinatra immer wieder Segfaults
-auftreten.</dd>
-<dt>Ruby 1.9.3</dt>
-<dd>1.9.3 wird vollständig unterstützt und empfohlen. Achtung, bei einem
-Upgrade von einer früheren Version von Ruby zu Ruby 1.9.3 werden alle Sessions
-ungültig. Ruby 1.9.3 wird bis Sinatra 2.0 unterstützt werden.</dd>
-<dt>Ruby 2.x</dt>
-<dd>2.x wird vollständig unterstützt.</dd>
-<dt>Rubinius</dt>
-<dd>Rubinius (Version >= 2.x) wird offiziell unterstützt. Es wird empfohlen, den
-<a href="http://puma.io">Puma Server</a> zu installieren (<tt>gem install puma
-</tt>)</dd>
-<dt>JRuby</dt>
-<dd>Aktuelle JRuby Versionen werden offiziell unterstützt. Es wird empfohlen,
-keine C-Erweiterungen zu verwenden und als Server Trinidad zu verwenden
-(<tt>gem install trinidad</tt>).</dd>
-</dl>
-Die nachfolgend aufgeführten Ruby-Implementierungen werden offiziell nicht von
-Sinatra unterstützt, funktionieren aber normalerweise:
-*   Ruby Enterprise Edition
-*   Ältere Versionen von JRuby und Rubinius
-*   MacRuby (<tt>gem install control_tower</tt> wird empfohlen), Maglev, IronRuby
-*   Ruby 1.9.0 und 1.9.1
-Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht funktionieren,
-wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
-Implementierung liegt.
-Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
-(zukünftige Versionen von MRI) mit eingebunden. Es kann davon ausgegangen
-werden, dass Sinatra MRI auch weiterhin vollständig unterstützen wird.
-Sinatra sollte auf jedem Betriebssystem laufen, dass einen funktionierenden
-Ruby-Interpreter aufweist.
-Sinatra läuft aktuell nicht unter Cardinal, SmallRuby, BlueRuby oder Ruby <= 1.8.7.
-## Der neuste Stand (The Bleeding Edge)
-Um auf dem neusten Stand zu bleiben, kann der Master-Branch verwendet werden.
-Er sollte recht stabil sein. Ebenso gibt es von Zeit zu Zeit prerelease Gems,
-die so installiert werden:
-```shell
-gem install sinatra --pre
-```
-### Mit Bundler
-Wenn die Applikation mit der neuesten Version von Sinatra und
-[Bundler](http://bundler.io) genutzt werden soll, empfehlen wir den
-nachfolgenden Weg.
-Soweit Bundler noch nicht installiert ist:
-```shell
-gem install bundler
-```
-Anschließend wird eine `Gemfile`-Datei im Projektverzeichnis mit folgendem
-Inhalt erstellt:
-```ruby
-source :rubygems
-gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
-# evtl. andere Abhängigkeiten
-gem 'haml'                    # z.B. wenn du Haml verwendest...
-gem 'activerecord', '~> 3.0'  # ...oder ActiveRecord 3.x
-```
-Beachte: Hier sollten alle Abhängigkeiten eingetragen werden. Sinatras eigene,
-direkte Abhängigkeiten (Tilt und Rack) werden von Bundler automatisch aus dem
-Gemfile von Sinatra hinzugefügt.
-Jetzt kannst du deine Applikation starten:
-```shell
-bundle exec ruby myapp.rb
-```
-### Eigenes Repository
-Um auf dem neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
-angelegt werden. Gestartet wird in der Anwendung mit dem `sinatra/lib`-Ordner
-im `LOAD_PATH`:
-```shell
-cd myapp
-git clone git://github.com/sinatra/sinatra.git
-ruby -Isinatra/lib myapp.rb
-```
-Alternativ kann der `sinatra/lib`-Ordner zum `LOAD_PATH` in der Anwendung
-hinzugefügt werden:
-```ruby
-$LOAD_PATH.unshift File.dirname(__FILE__) + '/sinatra/lib'
-require 'rubygems'
-require 'sinatra'
-get '/ueber' do
-  "Ich laufe auf Version " + Sinatra::VERSION
-end
-```
-Um Sinatra-Code von Zeit zu Zeit zu aktualisieren:
-```shell
-cd myproject/sinatra
-git pull
-```
-### Gem erstellen
-Aus der eigenen lokalen Kopie kann nun auch ein globales Gem gebaut werden:
-```shell
-git clone git://github.com/sinatra/sinatra.git
-cd sinatra
-rake sinatra.gemspec
-rake install
-```
-Falls Gems als Root installiert werden sollen, sollte die letzte Zeile
-folgendermaßen lauten:
-```shell
-sudo rake install
-```
-## Versions-Verfahren
-Sinatra folgt dem sogenannten [Semantic Versioning](http://semver.org/), d.h.
-SemVer und SemVerTag.
-## Mehr
-*   [Projekt-Website](http://www.sinatrarb.com/) - Ergänzende Dokumentation,
-    News und Links zu anderen Ressourcen.
-*   [Mitmachen](http://www.sinatrarb.com/contributing.html) - Einen Fehler
-    gefunden? Brauchst du Hilfe? Hast du einen Patch?
-*   [Issue-Tracker](https://github.com/sinatra/sinatra/issues)
-*   [Twitter](https://twitter.com/sinatra)
-*   [Mailing-Liste](http://groups.google.com/group/sinatrarb)
-*   [#sinatra](irc://chat.freenode.net/#sinatra) auf http://freenode.net Es
-    gibt dort auch immer wieder deutschsprachige Entwickler, die gerne weiterhelfen.
-*   [Sinatra Book](https://github.com/sinatra/sinatra-book/) Kochbuch Tutorial
-*   [Sinatra Recipes](http://recipes.sinatrarb.com/) Sinatra-Rezepte aus der
-    Community
-*   API Dokumentation für die [aktuelle
-    Version](http://www.rubydoc.info//gems/sinatra) oder für
-    [HEAD](http://www.rubydoc.info/github/sinatra/sinatra) auf http://rubydoc.info
-*   [CI Server](https://travis-ci.org/sinatra/sinatra)