FastCGI dispatcher don't work

I know you probably can't create a unit test for this, but can you please give me some steps to reproduce it. Like what server is in front, apache or lighttpd?

I see similar behavior with IIS7 + FastCGI + Ruby One-Click installer 1.8.6-26

[03/Feb/2009:22:38:55 :: 1972] Ignoring unsupported signal USR1. [03/Feb/2009:22:38:55 :: 1972] Dispatcher failed to catch: undefined method env' for #<FCGI::CGI:0x424378c> (NoMethodError) C:/ruby/lib/ruby/gems/1.8/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:inserve' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:101:in process_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:151:inwith_signal_handler' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:99:in process_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:76:inprocess_each_request' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:612:in each_cgi' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:609:ineach' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:609:in each_cgi' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:75:inprocess_each_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:74:in catch' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:74:inprocess_each_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:49:in process!' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:23:inprocess!' c:/development/myapp/public/dispatch.fcgi:24 unhandled dispatch error

FWIW, I had IIS7 + FastCGI + Rails 2.2.2 working. All I did was update the app to Rails 2.3.0.

I think you might be expecting a different class of object for the request variable. I think you're expecting an FCGI::CGI::Request or CGI::Request, but the error log shows that you're getting an FCGI::CGI or CGI object instead.

Apache2 + mod_fastcgi + rails2.3. Application doesn't work.

dispatcher.fcgi shows me "502 Bad Gateway" and put nothing in logs

When I run dispatcher manually ($ ./public/dispatch.fcgi) there are the same errors (like in first post)

dispatcher.cgi shows "Application Error" that written in .htaccess and in logs there are:

/usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/cgi_process.rb:22:in __send__': You have a nil object when you didn't expect it! (NoMethodError) The error occurred while evaluating nil.env_table

from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/cgi_process.rb:22:in `dispatch_cgi'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/dispatcher.rb:79:in `dispatch_cgi'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/dispatcher.rb:29:in `dispatch'
from ./public/dispatch.cgi:10

Looking at the spec for the Rack FastCGI handler, 3 things immediately jump out at me:

• Line 8 : @host = '0.0.0.0' This is not a valid address on Windows. Should change to 127.0.0.1
• Line 14 : the use of fork fork is not implemented on Windows. The win32-process gem is needed to get this working (conditional require?)
• Line 16 : lighttpd There is an unstated dependency on Lighttpd

I'll try to get these in place and run the spec again. I think that is why all the examples in the spec fail right now:

C:\ruby\lib\ruby\gems\1.8\gems\rack-0.9.1\test>spec spec_rack_fastcgi.rb FFFFFFFFF

1) NotImplementedError in 'Rack::Handler::FastCGI startup' fork() function is unimplemented on this machine ./spec_rack_fastcgi.rb:14:in fork' ./spec_rack_fastcgi.rb:14:

2) Test::Unit::AssertionFailedError in 'Rack::Handler::FastCGI should respond' Exception raised: Class: <Errno::EADDRNOTAVAIL> Message: <"The requested address is not valid in its context. - connect(2)"> ---Backtrace--- C:/Ruby/lib/ruby/1.8/net/http.rb:564:in initialize' C:/Ruby/lib/ruby/1.8/net/http.rb:564:inopen' C:/Ruby/lib/ruby/1.8/net/http.rb:564:in connect' C:/Ruby/lib/ruby/1.8/timeout.rb:48:intimeout' C:/Ruby/lib/ruby/1.8/timeout.rb:76:in timeout' C:/Ruby/lib/ruby/1.8/net/http.rb:564:inconnect' C:/Ruby/lib/ruby/1.8/net/http.rb:557:in do_start' C:/Ruby/lib/ruby/1.8/net/http.rb:546:instart' C:/Ruby/lib/ruby/1.8/net/http.rb:440:in start' ./testrequest.rb:17:inGET'

./spec_rack_fastcgi.rb:23

./spec_rack_fastcgi.rb:22:

3) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should be a lighttpd' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:28:

4) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have rack headers' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:38:

5) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have CGI headers on GET' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:46:

6) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have CGI headers on POST'

The requested address is not valid in its context. - connect(2) ./testrequest.rb:31:in POST' ./spec_rack_fastcgi.rb:63:

7) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should support HTTP auth' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:74:

8) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should set status' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:79:

9) TypeError in 'Rack::Handler::FastCGI shutdown' wrong argument type nil (expected Fixnum) ./spec_rack_fastcgi.rb:86:in kill' ./spec_rack_fastcgi.rb:86:

Finished in 1.23 seconds

9 examples, 9 failures

I'm getting the same error. Running on hostingrails.com with Apache.

05/Feb/2009:13:10:16 :: 15387] Dispatcher failed to catch: request: #<FCGI::CGI:0xb6ecab60 @args=nil, @params={}, @cookies={"_trunk_session"=>["BAh7ByIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOhFub3RpY2VfZXJyb3IiaFNvcnJ5ISBUaGlzIGFjY291bnQgaW4gbm90IHJlZ2lzdGVyZWQgd2l0aCB1cy4gUGxlYXNlIGVuc3VyZSB0aGF0IHlvdSBoYXZlIGVudGVyZWQgdGhlIGNvcnJlY3QgdXJsLgY6CkB1c2VkewY7BkY6DGNzcmZfaWQiJWY4MzI5NDU2NDNiMmMwYjAyMzdiNTk0YmUzNzI4NGMz--014da862ca2ba93f9d3be2e3121afad5d8b2bc91"]}, @output_hidden=nil, @request=#<FCGI:0xb6ecb510>, @output_cookies=nil, @multipart=false> (RuntimeError)
  /home/mygalax/webapps/dev/vendor/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:in `serve'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:101:in `process_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:151:in `with_signal_handler'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:99:in `process_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:76:in `process_each_request'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in `each_cgi'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each_cgi'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:75:in `process_each_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `catch'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `process_each_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:49:in `process!'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:23:in `process!'
  dispatch.fcgi:25
unhandled dispatch error

Whoops, didn't realize that the error was actually different that time. I've also gotten:

[05/Feb/2009:13:08:49 :: 14855] Dispatcher failed to catch: undefined method `env' for #<FCGI::CGI:0xb6f5ff1c> (NoMethodError)
  /home/mygalax/webapps/dev/vendor/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:in `serve'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:101:in `process_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:151:in `with_signal_handler'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:99:in `process_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:76:in `process_each_request'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in `each_cgi'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each'
  /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each_cgi'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:75:in `process_each_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `catch'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `process_each_request'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:49:in `process!'
  /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:23:in `process!'
  dispatch.fcgi:25
unhandled dispatch error

Crap. You can ignore the "Dispatcher failed to catch: request" error. That was my fault. The "env" one still stands though. Sorry about that.

Awesome work Peter!

Alexander and Will does this fix your issue?

No problem. I wasn't convinced it was exactly the right fix, just the start of one. I'll look into the tests and see if I can figure anything out. In the meantime if anyone else wants to build on what I've done they're more than welcome to.

Patch was no good on windows/IIS7:

Dispatcher failed to catch: Bad file descriptor (Errno::EBADF) c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:in write' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:inid' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:in process_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:153:inwith_signal_handler' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:100:in process_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:77:inprocess_each_request' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:606:in each_cgi' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:76:inprocess_each_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:75:in catch' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:75:inprocess_each_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:50:in process!' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:24:inprocess!' c:/development/myapp/public/dispatch.fcgi:24 unhandled dispatch error

Yeah, one problem I see is that the tests just mock out the requests. So we're just assuming that we get a certain kind of object FCGI::Request, but we're actually getting FCGI::CGI. Nothing is actually testing to make sure we're getting the right object. Secondly, the C based FCGI doesn't appear to include the FCGI::Request class. I had to force it to load the pure Ruby version of FCGI for that bit to work. I haven't yet hunted down where the FCGI::CGI request is coming from so I'm not sure if it's a problem with what Rack is providing or what Rails is expecting.

As far as I could have a look at it problem was that provider.each_cgi sends a different object then Rack is expecting. The solution for me was to change it to provider.each, but I know this breaks some other things down the code, so someone with some clue about the whole thing should have a look.

@Jan, that fits with what I'm seeing. If you open up the fcgi gem (0.8.7) you see that in lib/fcgi.rb FCGI::each_cgi explicitly returns a CGI object. Then the fcgi_handler.rb goes on to call methods that aren't defined on the CGI object. The only possible explanations I can think of are that someone just goofed and thought it was a Request object (which my patch changes it to), or the CGI class is defined differently somewhere else (possibly Ruby 1.9?).

So before we can do a proper fix there are a few questions we need answered: 1) What kind of object should we be expecting. Should it be a CGI object as the variable naming implies? Or should it be a Request object. 2a) If a CGI object, should we be converting it to a Request or instead calling methods that actually exist on the CGI object (i.e. stdinput, stdoutput, env_table)? 2b) If a Request object, how should it be generated? Is FCGI::each the appropriate way?

Once we can answer these questions I think we can then get a full fix out the door.

I've verified it against lighttpd on OS X. Can you guys please test on windows.

Confirmed working on IIS7 + FastCGI.

Confirmed on Apache/2.2.8 (Unix)

Sweet!

I'm going try to get those fancy signal handlers pushed up to Rack core now.

Sounds good. Let me know if you need any help with testing.

Peter,.. You said you were on HostingRails.com and that you got this working?

I am butting up against this problem too.

starting [05/Mar/2009:04:50:43 :: 4414] Dispatcher failed to catch: undefined method env' for #<FCGI::CGI:0xb75be458> (NoMethodError) /usr/local/lib/ruby/gems/1.8/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:inserve' /home/gfmerde/rhlebm3/vendor/rails/railties/lib/fcgi_handler.rb:101:in process_request' blah blah blah

Am I able to apply your patch locally to something/somewhere in my app, or do I have to convince someone at hostingrails.com to do this? Or do I have to renounce 2.3 ? :-( sniff.

My out-of-bandwidth email is shawn@shawnkoppenhoefer.com by the way. Thanks!

@Shawn,

You'll want to freeze Rails into vendor to avoid being stuck with HostingRails' version. If you freeze edge, you should be set. If you want to freeze 2.3 RC1 then try applying Joshua's patch here: http://github.com/rails/rails/co...