- - absolute_redirects
- -
-
- 如果被禁用，Sinatra会允许使用相对路径重定向， 但是，Sinatra就不再遵守
- RFC 2616标准 (HTTP 1.1), 该标准只允许绝对路径重定向。
-
+ - absolute_redirects
+ -
+ 如果被禁用，Sinatra 会允许使用相对路径重定向。
+ 然而这样的话，Sinatra 就不再遵守 RFC 2616 (HTTP 1.1), 该协议只允许绝对路径重定向。
+
+ -
+ 如果你的应用运行在一个未恰当设置的反向代理之后，你需要启用这个选项。
+ 注意 url 辅助方法仍然会生成绝对 URL，除非你传入false 作为第二参数。
+
+ - 默认禁用。
-
- 如果你的应用运行在一个未恰当设置的反向代理之后，
- 你需要启用这个选项。注意 url 辅助方法 仍然会生成绝对 URL，除非你传入
- false 作为第二参数。
-
-
- 默认禁用。
-
-
+ - add_charset
+ -
+ 设置 content_type 辅助方法会自动为媒体类型加上字符集信息。
+ 你应该添加而不是覆盖这个选项:
+ settings.add_charset << "application/foobar"
+
- - add_charset
- -
-
- 设定 content_type 辅助方法会 自动加上字符集信息的多媒体类型。
-
+ - app_file
+ -
+ 主应用文件的路径，用来检测项目的根路径， views 和 public 文件夹和内联模板。
+
-
- 你应该添加而不是覆盖这个选项:
- settings.add_charset << "application/foobar"
-
-
+ - bind
+ -
+ 绑定的 IP 地址 (默认: 0.0.0.0，开发环境下为 localhost)。
+ 仅对于内置的服务器有用。
+
- - app_file
- -
- 主应用文件，用来检测项目的根路径， views和public文件夹和内联模板。
-
+ - default_encoding
+ - 默认编码 (默认为 "utf-8")。
- - bind
- -
- 绑定的IP 地址 (默认: 0.0.0.0)。 仅对于内置的服务器有用。
-
+ - dump_errors
+ - 在日志中显示错误。
- - default_encoding
- -
- 默认编码 (默认为 "utf-8")。
-
+ - environment
+ -
+ 当前环境，默认是 ENV['RACK_ENV']，
+ 或者 "development" (如果 ENV['RACK_ENV'] 不可用)。
+
- - dump_errors
- -
- 在log中显示错误。
-
+ - logging
+ - 使用 logger。
- - environment
- -
- 当前环境，默认是 ENV['RACK_ENV']， 或者 "development" 如果不可用。
-
+ - lock
+ - 对每一个请求放置一个锁，只使用进程并发处理请求。
+ - 如果你的应用不是线程安全则需启动。默认禁用。
- - logging
- -
- 使用logger
-
+ - method_override
+ -
+ 使用 _method 魔法，以允许在不支持的浏览器中在使用 put/delete 方法提交表单。
+
- - lock
- -
-
- 对每一个请求放置一个锁， 只使用进程并发处理请求。
-
+ - port
+ - 监听的端口号。只对内置服务器有用。
-
- 如果你的应用不是线程安全则需启动。 默认禁用。
-
-
+ - prefixed_redirects
+ -
+ 如果没有使用绝对路径，是否添加 request.script_name 到重定向请求。
+ 如果添加，redirect '/foo' 会和 redirect to('/foo') 相同。
+ 默认禁用。
+
- - method_override
- -
- 使用 _method 魔法以允许在旧的浏览器中在 表单中使用 put/delete 方法
-
+ - protection
+ - 是否启用网络攻击防护。参见上面的保护部分
- - port
- -
- 监听的端口号。只对内置服务器有用。
-
+ - public_dir
+ - public_folder 的别名。见下文。
- - prefixed_redirects
- -
- 是否添加 request.script_name 到
- 重定向请求，如果没有设定绝对路径。那样的话 redirect '/foo' 会和
- redirect to('/foo')起相同作用。默认禁用。
-
+ - public_folder
+ -
+ public 文件存放的路径。只有启用了静态文件服务（见下文的 static）才会使用。
+ 如果未设置，默认从 app_file 推断。
+
- - public_folder
- -
- public文件夹的位置。
-
+ - reload_templates
+ -
+ 是否每个请求都重新载入模板。在开发模式下开启。
+
- - reload_templates
- -
- 是否每个请求都重新载入模板。 在development mode和 Ruby 1.8.6
- 中被企业（用来 消除一个Ruby内存泄漏的bug）。
-
+ - root
+ - 到项目根目录的路径。默认从 app_file 设置推断。
- - root
- -
- 项目的根目录。
-
+ - raise_errors
+ -
+ 抛出异常（会停止应用）。
+ 当 environment 设置为 "test" 时会默认开启，其它环境下默认禁用。
+
- - raise_errors
- -
- 抛出异常（应用会停下）。
-
+ - run
+ - 如果启用，Sinatra 会负责 web 服务器的启动。若使用 rackup 或其他方式则不要启用。
- - run
- -
- 如果启用，Sinatra会开启web服务器。 如果使用rackup或其他方式则不要启用。
-
+ - running
+ - 内置的服务器在运行吗？ 不要修改这个设置！
- - running
- -
- 内置的服务器在运行吗？ 不要修改这个设置！
-
+ - server
+ - 服务器，或用于内置服务器的服务器列表。顺序表明了优先级，默认顺序依赖 Ruby 实现。
- - server
- -
- 服务器，或用于内置服务器的列表。 默认是 [‘thin’, ‘mongrel’, ‘webrick’],
- 顺序表明了 优先级。
-
+ - sessions
+ -
+ 使用 Rack::Session::Cookie，启用基于 cookie 的会话。
+ 查看“使用会话”部分以获得更多信息。
+
- - sessions
- -
- 开启基于cookie的sesson。
-
+ - show_exceptions
+ -
+ 当有异常发生时，在浏览器中显示一个 stack trace。
+ 当 environment 设置为 "development" 时，默认启用，
+ 否则默认禁用。
+
+ -
+ 也可以设置为 :after_handler，
+ 这会在浏览器中显示 stack trace 之前触发应用级别的错误处理。
+
- - show_exceptions
- -
- 在浏览器中显示一个stack trace。
-
+ - static
+ - 决定 Sinatra 是否服务静态文件。
+ - 当服务器能够自行服务静态文件时，会禁用。
+ - 禁用会增强性能。
+ - 在经典风格中默认启用，在模块化应用中默认禁用。
- - static
- -
- Sinatra是否处理静态文件。 当服务器能够处理则禁用。 禁用会增强性能。
- 默认开启。
-
+ - static_cache_control
+ -
+ 当 Sinatra 提供静态文件服务时，设置此选项为响应添加 Cache-Control 首部。
+ 使用 cache_control 辅助方法。默认禁用。
+
+ -
+ 当设置多个值时使用数组：
+ set :static_cache_control, [:public, :max_age => 300]
+
- - views
- -
- views 文件夹。
-
+ - threaded
+ -
+ 若设置为 true，会告诉 Thin 使用 EventMachine.defer 处理请求。
+
+
+ - traps
+ - Sinatra 是否应该处理系统信号。
+
+ - views
+ - views 文件夹的路径。若未设置则会根据 app_file 推断。
+
+ - x_cascade
+ - 若没有路由匹配，是否设置 X-Cascade 首部。默认为 true。
+## 环境
+
+Sinatra 中有三种预先定义的环境："development"、"production" 和 "test"。
+环境可以通过 `RACK_ENV` 环境变量设置。默认值为 "development"。
+在开发环境下，每次请求都会重新加载所有模板，
+特殊的 `not_found` 和 `error` 错误处理器会在浏览器中显示 stack trace。
+在测试和生产环境下，模板默认会缓存。
+
+在不同的环境下运行，设置 `RACK_ENV` 环境变量：
+
+```shell
+RACK_ENV=production ruby my_app.rb
+```
+
+可以使用预定义的三种方法： `development?`、`test?` 和 `production?` 来检查当前环境：
+
+```ruby
+get '/' do
+ if settings.development?
+ "development!"
+ else
+ "not development"
+ end
+end
+```
## 错误处理
-错误处理在与路由和前置过滤器相同的上下文中运行，
+错误处理器在与路由和 before 过滤器相同的上下文中运行，
这意味着你可以使用许多好东西，比如 `haml`, `erb`, `halt`，等等。
### 未找到
-当一个 `Sinatra::NotFound` 错误被抛出的时候，
-或者响应状态码是404，`not_found` 处理器会被调用：
+当一个 `Sinatra::NotFound` 错误被抛出时，或者当响应的状态码是 404 时，
+会调用 `not_found` 处理器：
-~~~~ruby
+```ruby
not_found do
- 'This is nowhere to be found'
+ 'This is nowhere to be found.'
end
-~~~~
+```
### 错误
-`error` 处理器，在任何路由代码块或者过滤器抛出异常的时候会被调用。
-异常对象可以通过`sinatra.error` Rack 变量获得：
+在任何路由代码块或过滤器抛出异常时，会调用 `error` 处理器。
+但注意在开发环境下只有将 show exceptions 项设置为 `:after_handler` 时，才会生效。
-~~~~ruby
+```ruby
+set :show_exceptions, :after_handler
+```
+
+可以用 Rack 变量 `sinatra.error` 访问异常对象：
+
+```ruby
error do
'Sorry there was a nasty error - ' + env['sinatra.error'].message
end
-~~~~
+```
自定义错误：
-~~~~ruby
+```ruby
error MyCustomError do
'So what happened was...' + env['sinatra.error'].message
end
-~~~~
+```
-那么，当这个发生的时候：
+当下面的代码执行时：
-~~~~ruby
+```ruby
get '/' do
raise MyCustomError, 'something bad'
end
-~~~~
+```
-你会得到：
+你会得到错误信息：
- So what happened was... something bad
+```
+So what happened was... something bad
+```
-另一种替代方法是，为一个状态码安装错误处理器：
+或者，你也可以为状态码设置错误处理器：
-~~~~ruby
+```ruby
error 403 do
'Access forbidden'
end
@@ -1645,29 +2233,28 @@ end
get '/secret' do
403
end
-~~~~
+```
-或者一个范围：
+或者为某个范围内的状态码统一设置错误处理器：
-~~~~ruby
+```ruby
error 400..510 do
'Boom'
end
-~~~~
+```
-在运行在development环境下时，Sinatra会安装特殊的 `not_found` 和 `error`
-处理器。
+在开发环境下，Sinatra会使用特殊的 `not_found` 和 `error` 处理器，
+以便在浏览器中显示美观的 stack traces 和额外的调试信息。
## Rack 中间件
-Sinatra 依靠 [Rack](http://rack.github.io/), 一个面向Ruby
-web框架的最小标准接口。
-Rack的一个最有趣的面向应用开发者的能力是支持“中间件”——坐落在服务器和你的应用之间，
-监视 并/或 操作HTTP请求/响应以 提供多样类型的常用功能。
+Sinatra 依赖 [Rack](http://rack.github.io/), 一个面向 Ruby 网络框架的最小化标准接口。
+Rack 最有趣的功能之一是支持“中间件”——位于服务器和你的应用之间的组件，
+它们监控或操作 HTTP 请求/响应以提供多种常用功能。
-Sinatra 让建立Rack中间件管道异常简单， 通过顶层的 `use` 方法：
+Sinatra 通过顶层的 `use` 方法，让建立 Rack 中间件管道异常简单：
-~~~~ruby
+```ruby
require 'sinatra'
require 'my_custom_middleware'
@@ -1677,29 +2264,33 @@ use MyCustomMiddleware
get '/hello' do
'Hello World'
end
-~~~~
+```
-`use` 的语义和在
-[Rack::Builder](http://www.rubydoc.info/github/rack/rack/master/Rack/Builder)
-DSL(在rack文件中最频繁使用)中定义的完全一样。例如，`use` 方法接受
-多个/可变 参数，包括代码块：
+`use` 的语义和在 [Rack::Builder](http://www.rubydoc.info/github/rack/rack/master/Rack/Builder)
+DSL (在 rackup 文件中最频繁使用)中定义的完全一样。例如，`use` 方法接受
+多个/可变参数，以及代码块：
-~~~~ruby
+```ruby
use Rack::Auth::Basic do |username, password|
username == 'admin' && password == 'secret'
end
-~~~~
+```
-Rack中分布有多样的标准中间件，针对日志，
-调试，URL路由，认证和session处理。 Sinatra会自动使用这里面的大部分组件，
-所以你一般不需要显示地 `use` 他们。
+Rack 拥有有多种标准中间件，用于日志、调试、URL 路由、认证和会话处理。
+根据配置，Sinatra 可以自动使用这里面的许多组件，
+所以你一般不需要显式地 `use` 它们。
+
+你可以在 [rack](https://github.com/rack/rack/tree/master/lib/rack)、
+[rack-contrib](https://github.com/rack/rack-contrib#readm) 或
+[Rack wiki](https://github.com/rack/rack/wiki/List-of-Middleware)
+中找到有用的中间件。
## 测试
-Sinatra的测试可以使用任何基于Rack的测试程序库或者框架来编写。
-[Rack::Test](http://gitrdoc.com/brynary/rack-test) 是推荐候选：
+可以使用任何基于 Rack 的测试程序库或者框架来编写Sinatra的测试。
+推荐使用 [Rack::Test](http://www.rubydoc.info/github/brynary/rack-test/master/frames)：
-~~~~ruby
+```ruby
require 'my_sinatra_app'
require 'minitest/autorun'
require 'rack/test'
@@ -1726,22 +2317,20 @@ class MyAppTest < Minitest::Test
assert_equal "You're using Songbird!", last_response.body
end
end
-~~~~
+```
-请注意: 内置的 Sinatra::Test 模块和 Sinatra::TestHarness 类 在 0.9.2
-版本已废弃。
+注意：如果你使用 Sinatra 的模块化风格，应该用你应用的类名替代 `Sinatra::Application`。
-## Sinatra::Base - 中间件，程序库和模块化应用
+## Sinatra::Base - 中间件、库和模块化应用
-把你的应用定义在顶层，对于微型应用这会工作得很好，
-但是在构建可复用的组件时候会带来客观的不利， 比如构建Rack中间件，Rails
-metal，带有服务器组件的简单程序库，
-或者甚至是Sinatra扩展。顶层的DSL污染了Object命名空间，
-并假定了一个微型应用风格的配置 (例如, 单一的应用文件， ./public 和
-./views 目录，日志，异常细节页面，等等）。 这时应该让 Sinatra::Base
-走到台前了：
+在顶层定义你的应用很适合微型项目，
+但是在构建可复用的组件（如 Rack 中间件、Rails metal、带服务器组件的库或 Sinatra 扩展）时，
+却有相当大的缺陷。
+顶层 DSL 认为你采用的是微型应用风格的配置 (例如：唯一应用文件、
+`./public` 和 `./views` 目录、日志、异常细节页面等）。
+如果你的项目不采用微型应用风格，应该使用 `Sinatra::Base`：
-~~~~ruby
+```ruby
require 'sinatra/base'
class MyApp < Sinatra::Base
@@ -1752,120 +2341,167 @@ class MyApp < Sinatra::Base
'Hello world!'
end
end
-~~~~
+```
-Sinatra::Base子类可用的方法实际上就是通过顶层 DSL 可用的方法。
-大部分顶层应用可以通过两个改变转换成Sinatra::Base组件：
+Sinatra::Base 的子类可以使用的方法实际上就是顶层 DSL 中可以使用的方法。
+大部分顶层应用可以通过两方面的改变转换为 Sinatra::Base 组件：
-- 你的文件应当引入 `sinatra/base` 而不是 `sinatra`;
- 否则，所有的Sinatra的 DSL 方法将会被引进到 主命名空间。
+* 你的文件应当引入 `sinatra/base` 而不是 `sinatra`；
+否则，Sinatra 的所有 DSL 方法将会被导入主命名空间。
-- 把你的应用的路由，错误处理，过滤器和选项放在
- 一个Sinatra::Base的子类中。
+* 把应用的路由、错误处理器、过滤器和选项放在一个 Sinatra::Base 的子类中。
-`+Sinatra::Base+` 是一张白纸。大部分的选项默认是禁用的，
-包含内置的服务器。参见
-[选项和配置](http://www.sinatrarb.com/configuration.html)
-查看可用选项的具体细节和他们的行为。
+`Sinatra::Base` 是一个白板。大部分选项（包括内置的服务器）默认是禁用的。
+可以参考[配置](http://www.sinatrarb.com/configuration.html)
+以查看可用选项的具体细节和它们的行为。如果你想让你的应用更像顶层定义的应用（即经典风格），
+你可以继承 `Sinatra::Applicaiton`。
-### 模块化 vs. 传统的方式
+```ruby
+require 'sinatra/base'
-与通常的认识相反，传统的方式没有任何错误。
-如果它适合你的应用，你不需要转换到模块化的应用。
+class MyApp < Sinatra::Application
+ get '/' do
+ 'Hello world!'
+ end
+end
+```
-和模块化方式相比只有两个缺点:
+### 模块化风格 vs. 经典风格
-- 你对每个Ruby进程只能定义一个Sinatra应用，如果你需要更多，
- 切换到模块化方式。
+与通常的认识相反，经典风格并没有任何错误。
+如果它适合你的应用，你不需要切换到模块化风格。
-- 传统方式使用代理方法污染了 Object 。如果你打算 把你的应用封装进一个
- library/gem，转换到模块化方式。
+与模块化风格相比，经典风格的主要缺点在于，每个 Ruby 进程只能有一个 Sinatra 应用。
+如果你计划使用多个 Sinatra 应用，应该切换到模块化风格。
+你也完全可以混用模块化风格和经典风格。
-没有任何原因阻止你混合模块化和传统方式。
+如果从一种风格转换到另一种，你需要注意默认设置中的一些细微差别：
-如果从一种转换到另一种，你需要注意settings中的 一些微小的不同:
+