mongrel unicorn - Oct 2009 - weird unicorn_rails issue...

Hi all,

I just had a user on Rails v2.3.2 that had trouble[1] with the
out-of-the-box unicorn_rails, but was worked around by using the
following RAILS_ROOT/config.ru file with plain "unicorn" and
manually setting RAILS_ENV in the shell environment

  require ''config/environment''
  use Rails::Rack::LogTailer
  map("/") do
    use Rails::Rack::Static
    run ActionController::Dispatcher.new
  end

script/server + WEBrick worked out-of-the-box, as well.

Oddly, the same config.ru file does not work with "unicorn_rails",
either (even when the "config.ru" file is explicitly specified);
only with "unicorn".

So I''m a bit perplexed...


[1] - by "trouble", I mean the app became very subtly broken.  Query
parameters (it was a GET request) appeared to be handled correctly, but
the app was not returning the same results.  I looked briefly at the
app and noticed *something* was a bit suspicious:

    -------------- app/controllers/foo_controller.rb -------------
    class FooController < ApplicationController
      def index
        all_params = some_weird_params_generated
        results = BarController.new.action(all_params)
      end
    end
    -------------- app/controllers/bar_controller.rb -------------
    class BarController < ApplicationController
      def action(all_params)
        do_something
      end
    end
    --------------------------------------------------------------

That is, it creates a new controller from within one controller inside
one action.  Note that I''m not 100% certain this responsible for the
breakage we were seeing, but it certainly does look like suspicious
Rails code to me.


I haven''t decided if I''ll spend time to fix/debug this, but at
least
I''ll document it here if somebody wants to look into it further.

-- 
Eric Wong

In short: upgrade to Rails 2.3.4 (or later)

ref: http://mid.gmane.org/20091014221552.GA30624 at dcvr.yhbt.net
Note: the workaround described in the article above only made
the issue more subtle and we didn''t notice them immediately.
---

  Eric Wong <normalperson at yhbt.net> wrote:
  > Hi all,
  > 
  > I just had a user on Rails v2.3.2 that had trouble[1] with the
  > out-of-the-box unicorn_rails, but was worked around by using the
  > following RAILS_ROOT/config.ru file with plain "unicorn" and
  > manually setting RAILS_ENV in the shell environment
  > 
  >   require ''config/environment''
  >   use Rails::Rack::LogTailer
  >   map("/") do
  >     use Rails::Rack::Static
  >     run ActionController::Dispatcher.new
  >   end
  > 
  > script/server + WEBrick worked out-of-the-box, as well.
  > 
  > Oddly, the same config.ru file does not work with
"unicorn_rails",
  > either (even when the "config.ru" file is explicitly
specified);
  > only with "unicorn".
  > 
  > So I''m a bit perplexed...
  > 
  > 
  > [1] - by "trouble", I mean the app became very subtly broken. 
Query
  > parameters (it was a GET request) appeared to be handled correctly, but
  > the app was not returning the same results.  I looked briefly at the
  > app and noticed *something* was a bit suspicious:
  > 
  >     -------------- app/controllers/foo_controller.rb -------------
  >     class FooController < ApplicationController
  >       def index
  >         all_params = some_weird_params_generated
  >         results = BarController.new.action(all_params)
  >       end
  >     end
  >     -------------- app/controllers/bar_controller.rb -------------
  >     class BarController < ApplicationController
  >       def action(all_params)
  >         do_something
  >       end
  >     end
  >     --------------------------------------------------------------
  > 
  > That is, it creates a new controller from within one controller inside
  > one action.  Note that I''m not 100% certain this responsible for
the
  > breakage we were seeing, but it certainly does look like suspicious
  > Rails code to me.
  > 
  > 
  > I haven''t decided if I''ll spend time to fix/debug this,
but at least
  > I''ll document it here if somebody wants to look into it further.
 KNOWN_ISSUES    |   13 +++++++++++++
 unicorn.gemspec |    4 ++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index 436997d..979ac9d 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -1,5 +1,18 @@
 = Known Issues
 
+* Rails 2.3.2 bundles its own version of Rack.  This may cause subtle
+  bugs when simultaneously loaded with the system-wide Rack Rubygem
+  which Unicorn depends on.  Upgrading to Rails 2.3.4 (or later) is
+  strongly recommended for all Rails 2.3.x users for this (and security
+  reasons).  Rails 2.2.x series (or before) did not bundle Rack and are
+  should be unnaffected.  If there is any reason which forces your
+  application to use Rails 2.3.2 and you have no other choice, then
+  you may edit your Unicorn gemspec and remove the Rack dependency.
+
+  ref: http://mid.gmane.org/20091014221552.GA30624 at dcvr.yhbt.net
+  Note: the workaround described in the article above only made
+  the issue more subtle and we didn''t notice them immediately.
+
 * Installing "unicorn" as a system-wide Rubygem and using the
   {isolate}[http://github.com/jbarnette/isolate] gem may cause issues if
   you''re using any of the bundled application-level libraries in
diff --git a/unicorn.gemspec b/unicorn.gemspec
index c5b4422..063b313 100644
--- a/unicorn.gemspec
+++ b/unicorn.gemspec
@@ -43,6 +43,10 @@ Gem::Specification.new do |s|
 
   s.test_files = test_files
 
+  # for people that are absolutely stuck on Rails 2.3.2 and can''t
+  # up/downgrade to any other version, the Rack dependency may be
+  # commented out.  Nevertheless, upgrading to Rails 2.3.4 or later is
+  # *strongly* recommended for security reasons.
   s.add_dependency(%q<rack>)
 
   # s.licenses = %w(GPLv2 Ruby) # licenses= method is not in older Rubygems
-- 
Eric Wong