Rack::Response#body vs ActionDispatch::Response#body

The definitions of #body in Rack::Response and
ActionDispatch::Response are competing and causing performance
problems with streaming responses. Rack::Response provides
attr_accessor :body, while ActionDispatch::Response overrides that as

    def body
      str = ''
      each { |part| str << part.to_s }

This is problematic in instances where a streaming body is used, due
to the definition of Rack::Response#close:

    def close
      body.close if body.respond_to?(:close)

Given these definitions, executing the Rack protocol on an
ActionDispatch::Response instance (calling '#each', then '#close')
causes the body to be enumerated twice -- once via the expected call
to #each, and a second time via the call chain #close -> #body ->
#each. See https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4554
for a user report of this problem.

This could be fixed by using the instance variable directly:

    def close
      @body.close if @body.respond_to?(:close)

However, I think ActionDispatch::Response's #body override is
dangerous and violates the principle of least surprise by removing the
symmetry between #body and #body=. IMHO, it would be better to remove
the override. If the concatenating behavior is necessary, supply a
method named #body_text or a similar name that makes it clear that it
disables streaming. This option causes numerous Rails test failures,
however, as many tests are written to expect #body to return a string.


I agree that would fix this particular issue. My reluctance with that
is that AD::Response#body would remain a dangerous method on its own,
because it does not obey the semantics established by the base class.
It's a Liskov Substitution Principle violation -- AD::Response cannot
be safely substituted where Rack::Response is expected.

ActionDispatch::Response has two modes:

  • A mode for building up a response that will then be passed to a Rack server. The only interface on this object is #each
  • A mode for taking a tuple of [status, headers, body] and making it available for inspection using the Response API.
    The #body method is for the second mode, which is mostly used in testing and debugging. The fact that #close calls the #body method is a mistake, causing a (slow) debugging method to get called in the (fast) Rack response mode.

We should probably be using a different method for the debugging version of body, if Rack is calling #close on the result from #body (maybe something like string_body). Alternatively, we may want to create a debugging response object, and a to_something method to convert a response to that, but I worry that it has untold potential for breakage.

Yehuda Katz
Architect | Strobe
(ph) 718.877.1325