rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / code / Atom feed
* Rack::Response#body vs ActionDispatch::Response#body
@ 2010-11-30 22:52 John Firebaugh
  2010-11-30 23:27 ` Konstantin Haase
  0 siblings, 1 reply; 3+ messages in thread
From: John Firebaugh @ 2010-11-30 22:52 UTC (permalink / raw)
  To: rubyonrails-core, rack-devel

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
follows:

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

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)
    end

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)
    end

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.

Thoughts?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Rack::Response#body vs ActionDispatch::Response#body
  2010-11-30 22:52 Rack::Response#body vs ActionDispatch::Response#body John Firebaugh
@ 2010-11-30 23:27 ` Konstantin Haase
  2010-12-01  0:52   ` John Firebaugh
  0 siblings, 1 reply; 3+ messages in thread
From: Konstantin Haase @ 2010-11-30 23:27 UTC (permalink / raw)
  To: rack-devel

I agree this is a Rails issue, accessing @body directly would be a step backwards since being able to override #body is part of the API imo.
Why not override #close in ActionDispatch::Response to avoid this issue?

Konstantin

On Nov 30, 2010, at 23:52 , John Firebaugh wrote:

> 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
> follows:
> 
>    def body
>      str = ''
>      each { |part| str << part.to_s }
>      str
>    end
> 
> 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)
>    end
> 
> 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)
>    end
> 
> 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.
> 
> Thoughts?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Rack::Response#body vs ActionDispatch::Response#body
  2010-11-30 23:27 ` Konstantin Haase
@ 2010-12-01  0:52   ` John Firebaugh
  0 siblings, 0 replies; 3+ messages in thread
From: John Firebaugh @ 2010-12-01  0:52 UTC (permalink / raw)
  To: rack-devel, rubyonrails-core

On Tue, Nov 30, 2010 at 3:27 PM, Konstantin Haase <k.haase@finn.de> wrote:
> Why not override #close in ActionDispatch::Response to avoid this issue?

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-12-01  0:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-30 22:52 Rack::Response#body vs ActionDispatch::Response#body John Firebaugh
2010-11-30 23:27 ` Konstantin Haase
2010-12-01  0:52   ` John Firebaugh

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/rack.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).