academus (Robert)

Ruby Rack 及其应用 (下)

academus — Wed, 24 May 2017 10:14:54 +0800

前言

Ruby Rack 及其应用（上）（左边链接到我的博客，这个是站内链接）对 Rack 的定义、基本原理和构建方法做了介绍，并且提到 Rails、Sinatra 等 web 框架都是在 Rack 之上构建的。现在让我们来看几个 Rack 作为中间件的典型例子：这也是 Rack 应用最活跃的领域。

如何使用 Rack 中间件

在开始之前让我们先了解一下如何使用中间件，这样你就可以动手尝试一下后面的例子。在之前的文章里我已经说明了如何在config.ru里配置中间件，这对于任何基于 Rack 的 web 框架，如 Rails、Sinatra，都是可行的。但 Rails 和 Sinatra 也有自己的方式来配置中间件。你应该全面了解这些方法，因为以不同的方式配置中间件，得到的中间件栈可能是不同的——有时候中间件在栈内的顺序很重要。

Rails 可以通过config.middleware来配置中间件，可以在application.rb或者environments/<environment>.rb文件中进行配置，具体请参考Rails Guide。
Sinatra 的方式比较简单，直接在 Rack 应用中使用use来配置即可，与config.ru十分相似，具体请参考Sinatra README。

另外，要注意：在config.ru中配置的中间件处于中间件栈的上层，在 Rails 或 Sinatra 应用中配置的中间件处于下层，用户请求自上而下通过栈内的中间件，任何一个中间件都可以终止用户请求而不向下传递它。

Auth

Rack 中间件可以用来做 HTTP 鉴权（authentication and authorization）。考虑一个简单的例子：假设你有一个 Rack app，只限管理员使用。那么你可以使用Rack::Auth::Basic这个中间件，例如：

# config.ru
require 'admin_app'

use Rack::Auth::Basic, 'my auth realm' do |username, password|
  # Your method returns true when passing. Otherwise the middleware returns
  # 400 to client.
  your_auth_method(username, password)
end

run AdminApp

说明：

Rack::Auth::Basic的实现在 rack gem（lib/rack/auth/basic.rb）里，在此不必require。
它使用HTTP Basic Auth做鉴权，在生产环境下要结合 HTTPS 使用才安全。

配置了中间件以后，AdminApp 不用做任何改变就被“用户名／密码”保护了起来，不论它是 Rails、Sinatra 或者别的什么基于 Rack 的应用。

这个例子虽然简单，但值得我们分析一下Rack::Auth::Basic的实现——如果我们想实现一个自己的鉴权中间件或者我们不想用 Basic Auth 的话。

它的实现也很简单，包括以下几个文件，其中需要说明的地方我用中文做了注释，英文注释是原有的。

# lib/rack/auth/basic.rb

require 'rack/auth/abstract/handler'
require 'rack/auth/abstract/request'

module Rack
  module Auth
    # Rack::Auth::Basic implements HTTP Basic Authentication, as per RFC 2617.
    #
    # Initialize with the Rack application that you want protecting,
    # and a block that checks if a username and password pair are valid.

    class Basic < AbstractHandler

      # 每个Rack都要响应的call方法
      def call(env)
        auth = Basic::Request.new(env)
        # unauthorized 方法返回401，要求客户端以指定的Auth方法（此处是Basic Auth）
        # 提供用户名／密码。我们可以在这里指定其他Auth方法，如OAuth
        return unauthorized unless auth.provided?
        # bad_request 方法返回400，提示客户端Auth方法错误，即非Basic Auth
        return bad_request unless auth.basic?

        if valid?(auth)
          # 鉴权成功后把username保存在环境变量里，以便其他的Rack中间件和应用访问
          # 这是一种常用的在Rack中间件和应用之间传递信息的方式
          env['REMOTE_USER'] = auth.username
          # 调用下一个Rack的call方法
          return @app.call(env)
        end

        unauthorized
      end

      private

      # 参考下面unauthorized方法的实现了解challenge的作用
      def challenge
        'Basic realm="%s"' % realm
      end

      def valid?(auth)
        @authenticator.call(*auth.credentials) #*)
      end

      class Request < Auth::AbstractRequest
        def basic?
          "basic" == scheme
        end

        def credentials
          @credentials ||= params.unpack("m*").first.split(/:/, 2)
        end

        def username
          credentials.first
        end
      end

    end
  end
end

# lib/rack/auth/abstract/handler.rb

module Rack
  module Auth
    # Rack::Auth::AbstractHandler implements common authentication functionality.
    #
    # +realm+ should be set for all handlers.

    class AbstractHandler

      attr_accessor :realm

      # 每个Rack中间件的initialize方法的第一个参数都是app，即在中间件栈中下一级的
      # 中间件或应用，其他的参数可选。这些参数都由Rack Builder传入，比如有
      #
      # use Rack::Auth::Basic, 'my auth realm' do |username, password|
      # ...
      # end
      # run AdminApp
      #
      # 则app=AdminApp, realm='my auth realm', authenticator=block
      def initialize(app, realm=nil, &authenticator)
        @app, @realm, @authenticator = app, realm, authenticator
      end

      private

      # 上面已经有了unauthorized方法的应用，需要说明的是此处challenge是一个方法：
      # Ruby方法的缺省值不必是常量，而且取值是在所在方法被调用时发生的。
      # 另外，HTTP server通过通过WWW-Authenticate header指定Auth的方法，具体可参考
      # https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate
      def unauthorized(www_authenticate = challenge)
        return [ 401,
          { CONTENT_TYPE => 'text/plain',
            CONTENT_LENGTH => '0',
            'WWW-Authenticate' => www_authenticate.to_s },
          []
        ]
      end

      def bad_request
        return [ 400,
          { CONTENT_TYPE => 'text/plain',
            CONTENT_LENGTH => '0' },
          []
        ]
      end

    end
  end
end

# lib/rack/auth/abstract/request.rb

module Rack
  module Auth
    # 这个类主要用于解析HTTP客户端请求的Authorization header，从中提取Auth方法
    # 和用户名、密码等信息。参考这里了解更多关于Authorization
    # https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization
    class AbstractRequest

      def initialize(env)
        @env = env
      end

      def provided?
        !authorization_key.nil?
      end

      def parts
        @parts ||= @env[authorization_key].split(' ', 2)
      end

      def scheme
        @scheme ||= parts.first && parts.first.downcase
      end

      def params
        @params ||= parts.last
      end

      private

      # 按照CGI的方式，HTTP客户端请求的header都会被冠以“HTTP_”前缀、全部大写、保存在env里，
      # 因此Authorization就成了HTTP_AUTHORIZATION
      AUTHORIZATION_KEYS = ['HTTP_AUTHORIZATION', 'X-HTTP_AUTHORIZATION', 'X_HTTP_AUTHORIZATION']

      def authorization_key
        @authorization_key ||= AUTHORIZATION_KEYS.detect { |key| @env.has_key?(key) }
      end

    end

  end
end

当然，我们不一定要实现一个自己的 Auth 中间件，可以借助于以下 Gems（也是中间件）：

devise 针对 Rails
omniauth 对于任何 Rack 应用

如果你了解了原理，使用别人开发的中间件也会更得心应手。

Session

Rack 中间件还可以实现 HTTP session。以 Sinatra 为例，文档上说可以这样启用 session：

require 'sinatra/base'

class App < Sinatra::Base
  enable :sessions # 启用session

  get '/sessions' do
    "value = " << session[:value].inspect # 使用session方法读
  end

  get '/sessions/:value' do
    session['value'] = params['value'] # 使用session方法写
  end
end

实际上以上代码相当于：

require 'sinatra/base'

class App < Sinatra::Base
  # 启用session
  use Rack::Session::Cookie, :secret => SecureRandom.hex(64)

  # ...
end

在上面的代码中：Rack::Session::Cookie就是用于实现 session 的中间件，use是 Sinatra 用于配制中间件的方法。另外，用于读写 session 变量的session方法也很简单：

# lib/sinatra/base.rb
module Sinatra
  module Helpers
    def session
      request.session
    end
    # ...
  end
end

其中request#session的实现是：

# lib/rack/request.rb
module Rack
  class Request
    def session;         @env['rack.session'] ||= {}              end
    # ...
  end
end

至于这个@env['rack.session']是怎么来的，让我们了解一下Rack::Session::Cookie的实现你就明白了。以下需要注意的地方我用中文做了注释，英文注释是原有的，也要注意。

# lib/rack/session/cookie.rb

module Rack
  module Session
    # HTTP session的主要行为都是在Abstract::ID里实现的，子类只需要实现session对象的
    # 保存和读取。除了cookie，还可以把它保存在Redis之类的数据库里，甚至直接保存在内存，
    # 如Rack::Session::Pool。
    class Cookie < Abstract::ID
      def get_session(env, sid)
        # ...
      end

      def set_session(env, sid, new_session, options)
        # ...
      end

      def destroy_session(env, sid, options)
        # ...
      end

      # ...
    end
  end
end

# lib/rack/session/abstract/id.rb

module Rack
  module Session
    module Abstract
      # 注意这个常量：Rack中间件把session对象保存在env的这个key下，也就是说，
      # 其他的Rack中间件和应用只有通过这个key才能访问session。
      ENV_SESSION_KEY = 'rack.session'.freeze
      ENV_SESSION_OPTIONS_KEY = 'rack.session.options'.freeze

      # 这就是我们在上面的Sinatra示例中通过session方法所访问的对象
      class SessionHash
        # ...
      end

      # ID sets up a basic framework for implementing an id based sessioning
      # service. Cookies sent to the client for maintaining sessions will only
      # contain an id reference. Only #get_session and #set_session are
      # required to be overwritten.
      #
      # All parameters are optional.
      # * :key determines the name of the cookie, by default it is
      #   'rack.session'
      # * :path, :domain, :expire_after, :secure, and :httponly set the related
      #   cookie options as by Rack::Response#add_cookie
      # * :skip will not a set a cookie in the response nor update the session state
      # * :defer will not set a cookie in the response but still update the session
      #   state if it is used with a backend
      # ...
      class ID
        # 注意：下面这个key虽然与ENV_SESSION_KEY的值相同，但意义不同：前者用于设置cookie，
        # 我们可以而且应当给它赋一个有意义的值，如“example.com”；后者用于在env中存取
        # seesion对象，我们无法、也不应该改变它的值。
        DEFAULT_OPTIONS = {
          :key =>           'rack.session',
          :path =>          '/',
          :domain =>        nil,
          :expire_after =>  nil,
          :secure =>        false,
          :httponly =>      true,
          :defer =>         false,
          :renew =>         false,
          :sidbits =>       128,
          :cookie_only =>   true,
          :secure_random => (::SecureRandom rescue false)
        }

        attr_reader :key, :default_options

        def initialize(app, options={})
          @app = app
          @default_options = self.class::DEFAULT_OPTIONS.merge(options)
          # ...
        end

        def call(env)
          context(env)
        end

        def context(env, app=@app)
          prepare_session(env)
          status, headers, body = app.call(env)
          commit_session(env, status, headers, body)
        end

        private

        def prepare_session(env)
          session_was                  = env[ENV_SESSION_KEY]
          # session对象在此建立并保存在env里，但session可以是lazy loading的，
          # 只在读取／写入时才访问实际的session存储。
          env[ENV_SESSION_KEY]         = session_class.new(self, env)
          env[ENV_SESSION_OPTIONS_KEY] = @default_options.dup
          env[ENV_SESSION_KEY].merge! session_was if session_was
        end

        # Acquires the session from the environment and the session id from
        # the session options and passes them to #set_session. If successful
        # and the :defer option is not true, a cookie will be added to the
        # response with the session id.
        def commit_session(env, status, headers, body)
          session = env[ENV_SESSION_KEY]
          options = session.options
          # ...
        end

        # ...

        # Allow subclasses to prepare_session for different Session classes
        def session_class
          SessionHash
        end

        # All thread safety and session retrieval procedures should occur here.
        # Should return [session_id, session].
        # If nil is provided as the session id, generation of a new valid id
        # should occur within.
        def get_session(env, sid)
          raise '#get_session not implemented.'
        end

        # All thread safety and session storage procedures should occur here.
        # Must return the session id if the session was saved successfully, or
        # false if the session could not be saved.
        def set_session(env, sid, session, options)
          raise '#set_session not implemented.'
        end

        # All thread safety and session destroy procedures should occur here.
        # Should return a new session id or nil if options[:drop]
        def destroy_session(env, sid, options)
          raise '#destroy_session not implemented'
        end
      end
    end
  end
end

以Rack::Session::Abstract::ID为基础，我们很容实现自己的 session 中间件。另外，如果你想用 Redis 做存贮，可以考虑redis-rack这个 Gem.

Log

Rack 中间件还可以做日志，这很容实现。让我来举两个简单的例子。

其一，在异常错误时做记录或者输出诊断信息：

class ExceptionCatcher
  def initialize(app)
    @app = app
  end

  def call(env)
    @app.call(env)
  rescue Exception => e
    # You can log it anywhere you like ...
    # And output any diagnostic info you prefer
    [500, ...]
  end
end

当你在 Rails 或者 Sinatra dev server 上做开发时，经常可以看到类似的诊断输出，实际上都是通过这样的中间件完成的。顺便说，Sinatra 使用的中间件是Sinatra::ShowExceptions，Rails 也有对应的，不妨查看一下它的中间件栈。

其二，对每个 HTTP 请求做记录，就像 Apache 的 access 日志那样。不过你可以记得更多一些，比如完成一次请求的耗时。在这方面Rack::CommonLogger已经做得不错了，不妨参考一下它的实现。

另外值得指出的是，当你要输出日志的时候，你需要一个 IO 输出对象，这时你有几个选择：

env['rack.errors']：一个 error stream 对象，该对象支持puts和flush方法。按照 Rack 规范，该对象必须由 Rack 服务器（如 Phusion Passenger）提供。
evn['rack.logger']："A common object interface for logging messages."，支持info、debug等方法，但不是 Rack 服务器必须提供的。Rack::Logger中间件利用 env['rack.errors'] 提供了一个简单的实现。

最后，欢迎你关注我的博客，了解更多技术资讯 ^_^

Ruby Rack 及其应用 (上)

academus — Mon, 14 Nov 2016 18:30:21 +0800

前言

你可能听说过 Rails、Sinatra 这些 Ruby Web 框架，也可能尝试过其中一、两个，但如果你还不了解 Rack 甚至根本没听说过它，那么你的 Ruby Web 开发还停留在表面：Ruby Rack 是前面这些 Ruby Web 框架的基础，Rails 和 Sinatra 都建立在它之上；不了解 Rack 的原理就无法真正理解你的 Ruby Web 应用的架构与工作机制、对一些复杂的问题也无能无力。任何一个正经的 Ruby Web 开发者都应该了解、掌握 Rack。

本文将深入浅出地介绍 Ruby Rack 和它的一些典型应用，如 Profiler、Logger 和 Session 等。

Ruby Rack

我在《Web 全栈技术指南》中简单介绍过 Ruby Rack[^1]。下面的内容是它的扩充与深入。

什么是 Ruby Rack

Ruby Rack 是一个接口，用于 Ruby Web 应用与应用服务器之间的交互，如图所示：

最左边的 User Agent 就是浏览器等客户端，它发起 HTTP 请求；中间的 Rack Server 是应用服务器 [^2]，它响应 HTTP 请求，并调用我们的 Rack 应用；最右边是我们的应用程序——它可能是一个 Rails 或者 Sinatra 应用。Rack 服务器和 Rack 应用程序之间通过 Rack 接口交互。

那么 Rack 接口是怎样的？就像这样：

# hello.rb - v0

app = proc do |env|
  ['200', {'Content-Type' => 'text/html'}, ['Hello, Rack!']]
end

这是一个最小的可以工作的 Rack 应用程序，它揭示了 Rack 接口：

一个响应call方法的对象（任何类型的对象都可以，上面只是以 proc 为例）
接受一个 Hash 类型的环境变量作为输入参数（它包含了全部的 HTTP 请求信息）
返回一个包含三个元素的数组，依次是：
1. HTTP 应答代码（status code）
2. 一个 Hash 类型的对象，包含 HTTP 应答头部信息（header）
3. 一个响应each方法的对象，其结果将作为 HTTP 应答消息的主体（body）

很简单不是么？（难的我都放在后面了，^_-）

只要再加两行代码，这个迷你的 Web 服务就能正式运行起来：

# hello.rb - v1

require 'rack'

app = proc do |env|
  ['200', {'Content-Type' => 'text/html'}, ['Hello, Rack!']]
end

Rack::Handler::WEBrick.run(app, :Port => 8090, :Host => '0.0.0.0')

在最后一行，我们用 Webrick[^3] 这个 Rack 服务器来 run 我们的 Rack 应用。

要运行上面的代码，先安装 Gem rack（如过你安装过 Rails 或者 Sinatra 那么它已经作为依赖被安装过了）：

gem install rack

假设以上代码保存在文件hello.rb中，执行

ruby hello.rb

就把我们的迷你服务器启动了。在浏览器中访问http://localhost:8090，快试试！

Rack Middleware

Rack 不是那么简单：现在让我们了解一下强大的 Rack 中间件（middleware）。

以下是一个中间件的例子 [^4]：

# timing.rb - v1

class Timing
  def initialize(app)
    @app = app
  end

  def call(env)
    ts = Time.now
    status, headers, body = @app.call(env)
    elapsed_time = Time.now - ts
    puts "Timing: #{env['REQUEST_METHOD']} #{env['REQUEST_URI']} #{elapsed_time.round(3)}"
    return [status, headers, body]
  end
end

我们可以这么使用它 [^5]：

# hello.rb - v2

require 'rack'
require './timing.rb'

app = proc do |env|
  ['200', {'Content-Type' => 'text/html'}, ['Hello, Rack!']]
end

Rack::Handler::WEBrick.run(Timing.new(app), :Port => 8090, :Host => '0.0.0.0')

快试试！看看现在我们的 Rack 应用有什么变化。

现在我来解释一下上面的程序。

Rack 中间件就是一个类，如上面的Timing，其对象响应一个call方法，这个方法的输入、输出规格与一般 Rack 应用一样。因此Timing.new(app)可以作为一个 Rack 应用直接传递给Rack::Handler::WEBrick.run。实际上，中间件可以这样一层套一层地层层嵌套下去，最后仍得出一个可以 call 的 Rack 应用。

Rack 中间件可以实现非常强大的功能。在上面的例子中，我们的 Timing 中间件为每一次调用计时，并把结果打印出来。这相当于一个 profiler。实际上中间件能做的事情更多：它可以检查内嵌应用程序@app的输入、输出，还可以修改它们。因此它还可以用于鉴权（authentication/authorization）、日志，或者给内嵌应用提供一些额外的功能，如 Session 等等。稍后我们会看到两个实际的例子。

rackup 和 Rack::Builder

rackup 和 Rack::Builder 都是 Gem rack 提供的工具，方便我们使用、构造 Rack 应用。

仍以前面的 hello Rack 和 Timing 中间件为例，实际上，我们一般这样定义我们的 Rack 应用：

# config.ru

require './hello.rb'
require './timing.rb'

use Timing
run Hello

以上代码保存在一个名为config.ru的文件中——它是 rackup 工具的缺省配置文件。

其中 hello.rb 的内容是：

# hello.rb - v3

class Hello
  def self.call(env)
    ['200', {'Content-Type' => 'text/html'}, ['Hello, Rack!']]
  end
end

这里我们定义了一个类Hello，它有一个call方法（回忆一下 Rack 的定义：任何响应call方法的对象）。

我们不需要再编写初始化 Rack 中间件和启动 Rack 服务器的代码——rackup 工具会为我们完成。

一切就绪以后，在命令行执行（要在包含 config.ru 的目录下）：

rackup

啊哈，我们的迷你服务器又启动了！

rackup 默认使用 Webrick 服务器，你也可以通过参数指定其他服务器。了解更多参数选项：

rackup -h

如果你想知道 rackup 是如何构造 Rack 应用、配置中间件的，你需要了解 Rack::Builder（Gem rack 安装目录下的 lib/rack/builder.rb）。具体代码这里就不做分析了。下面再举几个例子说明一下 config.ru 如何配置 Rack 应用和中间件。

如果你要使用多个中间件，可以：

# config.ru - multi-middlewares

require './app.rb'
require './middleware1.rb'
require './middleware2.rb'
require './middleware3.rb'

use Middleware1
use Middleware2
use Middleware3
run App

Rack::Builder 将依次应用这些中间件到App上，得出一个最终的 Rack 应用，效果如同以下代码：

rack_app = Middleware1.new(Middleware2.new(Middleware3.new(App)))

你还可以在 config.ru 中配置路由，如：

# config.ru - routes

require './main.rb'
require './admin.rb'
require './m1.rb'
require './m2.rb'

map '/' do
  use m1
  run Main
end

map '/admin' do
  use m2
  run Admin
end

这样所有以/admin/开头的请求都会交由Admin处理，其余则由Main处理。这种配置实际上开启了一种“Rack 组合”模式——由几个不同的 Rack 应用组成一个新的 Rack 应用。比如说：把一个 Rails 应用和一个 Sinatra 应用（它们都是标准的 Rack 应用）组合成一个新的 Rack 应用——脑洞很大，但完全可行！

另外，Rack 中间件是可以接受参数的——甚至可以带有 code block，比如：

# config.ru

require './hello.rb'
require './timing.rb'

use Timing, :pid => true, { puts "Timing is being initialized!" }
run Hello

这里的 timing.rb 内容如下：

# timing.rb - v2

class Timing
  def initialize(app, opts = {}, &b)
    @app = app
    @pid = opts[:pid]
    yield if block_given?
  end

  def call(env)
    ts = Time.now
    status, headers, body = @app.call(env)
    elapsed_time = Time.now - ts
    puts "Timing: #{Process.pid if @pid} #{env['REQUEST_METHOD']} #{env['REQUEST_URI']} #{elapsed_time.round(3)}"
    return [status, headers, body]
  end
end

Rails/Sinatra on Rack

Rails 和 Sinatra 都是标准的 Rack 应用框架——你可能已经注意到了，它们的项目根目录下一般都有一个 config.ru 文件。你可能会想：我从没编辑过这个文件，大概也就没有使用过中间件吧？错了！Rails 和 Sinatra 都可以在它们的应用程序内配置中间件，并且在缺省情况下已经为你配置了一大堆：

在一个 Rails 项目的根目录下运行：

bin/rails middleware

看看 Rails 为你配置的中间件栈有多深 [^6]：

use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x000000029a0838>
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Reloader
use ActionDispatch::Callbacks
use ActiveRecord::Migration::CheckPending
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
run Rails.application.routes

相比而言 Sinatra 要轻便许多：它有条件地配置了 4～7 个中间件（针对版本 v1.4.7），在 lib/sinatra/base.rb 中：

def setup_default_middleware(builder)
  builder.use ExtendedRack
  builder.use ShowExceptions       if show_exceptions?
  builder.use Rack::MethodOverride if method_override?
  builder.use Rack::Head
  setup_logging    builder
  setup_sessions   builder
  setup_protection builder
end

但是，不论这些 Rack 应用框架如何组织、定义自己的中间件栈，你都可以在 config.ru 中使用 Rack::Builder 所支持的标准语法来配置你的中间件——虽然一般情况下你不必这么做，但这样做有一个好处：你在 config.ru 中配置的中间件处于你的中间件栈顶部 [^7]，也就是说，它最先响应服务器的请求、最后给出答案，因此具有最大的权威。

Rack env

以为 Rack 就这么结束了？并没有！——我之前说过，Rack 没那么简单。前面我们只提了一下call接受一个环境变量env作为输入，并提到它包含了全部的 HTTP 请求信息，但并没有仔细讲讲它。现在是时候了——它很重要！

让我们检查一下 env 都包含些啥：

require 'rack'

app = proc do |env|
  env.to_a.sort_by {|e| e[0] }.each {|k, v| puts %Q(#{k}=#{v}) }
  [200, {}, []]
end

Rack::Handler::WEBrick.run(app, :Port => 8090)

这个简单的 Rack 应用会把 env 的内容都打印出来。照前面的样子启动它，然后访问它，你就能看到：

GATEWAY_INTERFACE=CGI/1.1
HTTP_ACCEPT=*/*
HTTP_HOST=localhost:8090
HTTP_USER_AGENT=curl/7.35.0
HTTP_VERSION=HTTP/1.1
PATH_INFO=/
QUERY_STRING=
REMOTE_ADDR=127.0.0.1
REMOTE_HOST=127.0.0.1
REQUEST_METHOD=GET
REQUEST_PATH=/
REQUEST_URI=http://localhost:8090/
SCRIPT_NAME=
SERVER_NAME=localhost
SERVER_PORT=8090
SERVER_PROTOCOL=HTTP/1.1
SERVER_SOFTWARE=WEBrick/1.3.1 (Ruby/2.3.0/2015-12-25)
rack.errors=#<IO:0x0000000220dad0>
rack.hijack=#<Proc:0x000000024176c8@/home/user/.rvm/gems/ruby-2.3.0/gems/rack-1.6.4/lib/rack/handler/webrick.rb:76 (lambda)>
rack.hijack?=true
rack.hijack_io=
rack.input=#<StringIO:0x000000024180a0>
rack.multiprocess=false
rack.multithread=true
rack.run_once=false
rack.url_scheme=http
rack.version=[1, 3]

这是我从 localhost 上用 curl 访问的输出，你的也应该差不多。除了那些大写的 CGI[^8] 变量，还有一些 rack.xxx 变量，这些都是由 Rack 服务器设置并传递给 Rack 应用程序的。

CGI 变量大都可以顾名思义，前面的 Timing 中间件作为一个示例也用到了REQUEST_METHOD和REQUEST_URI，这里就不详细介绍了，感兴趣的读者可以参考脚注 [^8]。下面对 rack.xxx 变量做一些介绍：

rack.input 一个 IO 对象，可以读取 raw HTTP request。
rack.errors 一个 IO 对象，用于错误输出。一般地，Rack 服务器会把它输出到服务器日志文件。它也是 Rack::Logger 和 Rack::CommonLogger 的输出对象。
rack.hijack、rack.hijack?和rack.hijack_io可以实现 websocket。
rack.multiprocess和rack.multithread: 这两个对象指示了 Rack 应用的运行环境是否是多进程、多线程。这里需要着重说明一下：Rack 服务器可以根据负载情况同时启用 Rack 应用的多个实例，既有可能通过多进程（每个进程一个实例），也有可能通过多线程（一个进程，多个线程，每线程一个实例），还可能把二者结合起来（多进程，同时每个进程内多线程实例）。服务器具体通过什么方式启动应用，每种服务器都不一样，你需要查看服务器的文档说明。比如 Phusion Passeger 可以使用多进程或者混合模式（在企业版中）；Unicorn 多进程；Thin 多线程（可配置）。一般来说使用多进程方式比较安全：如果要使用多线程，你不但要保证你的 Rack 应用是线程安全的，还要保证你用到的所有中间件都是线程安全的。
rack.run_once 这个变量说明服务器是否只运行你的 Rack 应用实例一次就把它释放掉。这就是说服务器会对每个 HTTP 请求构造一个新的 Rack 应用实例（包括所有的中间件初始化工作）。一般来说只有 CGI 服务器会这样做 [^9]（你肯定听说过 CGI 服务器效率不高吧？）。
rack.url_scheme http 或 https
rack.version Rack Spec 的版本（不是 Gem Rack 的版本）。我一直还没告诉你：Rack 不但是一个接口、一个 Gem 的名字，还是一个规范。

一般而言你不必直接操作这些 rack.xxx 变量（也不应该这么做，除非你十分清楚这么做的后果，像作者这样^_-），但是你应该清楚它们的意义，这有助于你深刻理解 Rack 以及处理一些复杂问题。另外，Rack env 不但可以用于从 Rack 服务器向 Rack 应用和中间件传递一些信息，还可以用于在 Rack 中间件之间或者中间件与应用之间传递消息。在本文的下半部我们将看到这是如何实现的，以及这样做的意义。

Rack 的介绍到此为止，本文下半部将介绍一些 Rack 技术的常见应用，如 Profiler、Logger 和 Session 等中间件，了解它们是如何工作的。同时，欢迎你关注我的博客，获得更多技术资讯。

[^1]: Web 服务器->编程语言与技术->Ruby [^2]: 常见的 Rack 应用服务器有 Phusion Passenger，Unicorn，Thin，Puma 和 Webrick 等等。 [^3]: Webrick 一般用于开发环境，你的生产环境应该使用 Phusion Passenger 或者 Unicorn 等高性能的 Rack 服务器。 [^4]: 我喜欢直接从代码开始，我也建议读者手工输入并运行全部的代码示例，并且反复强调一点：技术文章不要只去读，要做！ [^5]: 一般我们不这么用，后面的 rackup 一节会展示通常的用法，但二者的本质是一样的，只是表现形式不同。 [^6]: 更多关于 Rails on Rack 的信息可参考：Rails on Rack [^7]: 实际上 Rack 服务器也可以（而且并不少见）给 Rack 应用加上一些额外的中间件，用于输出 DEBUG 日志等一些工作。这些中间件在所有中间件栈的位置比 config.ru 中的还要“高”。 [^8]: CGI 即通用网关接口（Common Gateway Interface），我在《Web 全栈技术指南》的Web 服务器->编程语言与技术->CGI一节做过介绍。 [^9]: 细心的读者可能会问：Rack 应用难道不是对每个请求构造一个新的实例么？比如一个从 Sinatra::Base 继承来的类，对每次请求都会生成新的实例，成员变量也都重新初始化了。其实并没有！以 Sinatra 为例，它只是每次从初始化好的、无状态的 Rack 应用对象 dup 一个实例，用完就释放，下次再 dup 一个新的。具体你要看看 Sinatra 或者 Rails 的代码是如何做到的。

Linode Tokyo 机房不能访问了

academus — Sat, 15 Mar 2014 16:43:53 +0800

这两天的事，ping 不通，HTTP/SSH 访问也不通，目前只有网页 Lish 可以访问，而且经常断线。有遇到同样问题的朋友吗？我该怎么办？换 IP？换机房？还是？

Ruby Conf 大量照片

academus — Sun, 18 Nov 2012 21:48:28 +0800

关注我的围脖 http://weibo.com/acadamus