Eric Wong <[email protected]> wrote: > Travis Bell <[email protected]> wrote: > > Just a follow up, it looks like it was rack 1.1.0 causing the issues. > > I uninstalled it, and am now using rack 1.0.1 and the error has gone > > away. > > > > Why it worked with Thin + Rack 1.1.0 and not Unicorn, still not sure. > > Sorry, I keep getting distracted/interrupted while looking into this, > it's probably related to the Rack::Utils::HeaderHash optimizations[1] in > Rack 1.1.0 somehow interacting badly with Sinatra + Rack::Lint > > But Sinatra uses Rack::Response, so it shouldn't happen, but somehow > it does, I'll look at it more when I get a chance.
HI Travis, I can't seem to reproduce this with Sinatra 466cc74b8f393f98de227122c78ed55cb745cbc6, and Rack 1.1.0 with a basic "hello world" application. I'll need to know more about what your application does with response headers... Are you running any other middlewares or patches that could affect things inside Rack::Response or Rack::Utils? Unicorn takes a very strict interpretation of the Rack spec and always loads Rack::Lint in development mode. This makes Unicorn much more picky about applications/middleware that don't completely conform to the Rack spec. Thin itself doesn't appear to load Rack::Lint by default, but does running your application with "rackup -s thin -E development..." let you reproduce the failures you see with Unicorn? Thanks for any more info you can give us! -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
