Ruby Forum Ruby > Using Derrick Pallas' ruby fcgi dispatcher

I am trying to use the following dispatcher in lighttpd:
http://derrick.pallas.us/ruby-cgi/

Code looks fine, and first request looks fine. But subsequent requests
to the dispatcher via the webbrowser do not deliver the query
parameters in cgi.params - it's just empty. I have to restart lighttpd
oder wait for the dispatcher to die to get correct results again.

Is there something wrong with the dispatcher? Or with my code. Here's
a snippet of my code which is called thru the dispatcher:

---------------------
#!/usr/bin/env ruby

puts cgi.header

require 'yaml'
require 'rubygems'
require 'active_record'
require 'action_mailer'

...

puts cgi.params.inspect # <-- debug, it's empty on second request
params = cgi.params.select { |q,| %w{system keyword udh smstext
absender time client}.include? q }
params = Hash[*params.flatten]
---------------------

Third last line shows the problem...

Any clues?

Regards,
Kai

No clue, but I suggest you to add some:

> $stderr.puts "TEST X: #{cgi.params.inspect}"

...all over that dispatcher script to see where the problem starts (it 
will
log to lighttpd's error log).

 I also had many problems with fcgi and lighttpd mainly because it was 
setting
different environment variables than other webserver (webrick). To fix 
this I
first modify the environment table before I continue and so far I have 
no
problems:

>          ec['QUERY_STRING'] = ec['REQUEST_URI'].include?('?') ?
>              ec['REQUEST_URI'].scan(/.?\?(.*)/)[0][0] :
>              ""
>       end
>       ec
>     end
>   end
> end


... and in the dispatcher you do:

> FCGI.each_cgi do |cgi|
>   CGI::fix_env(cgi.env_table)


Maybe that helps...


Martin

Hallo!

Thank you for the suggestions.

On 9 Mai, 18:34, Martin Boese <boese...@gmx.de> wrote:
> No clue, but I suggest you to add some:
>
> > $stderr.puts "TEST X: #{cgi.params.inspect}"
>
> ...all over that dispatcher script to see where the problem starts (it will
> log to lighttpd's error log).

It starts right in the first line of the FCGI.each_cgi loop:

54 FCGI.each_cgi do |cgi|
55   $stderr.puts "TEST1: #{cgi.params.inspect}"

On first request the parameters are correct. On subsequent requests
the hash is just plain empty:

2008-05-13 15:30:23: (mod_fastcgi.c.2592) FastCGI-stderr: TEST1:
{"time"=>["jetzt"], ..., "keyword"=>["bla"]}
2008-05-13 15:30:44: (mod_fastcgi.c.2592) FastCGI-stderr: TEST1: {}

>  I also had many problems with fcgi and lighttpd mainly because it was setting
> different environment variables than other webserver (webrick). To fix this I
> first modify the environment table before I continue and so far I have no
> problems:

> class CGI [...]

I've put that class into my dispatcher in front of the loop and
patched the loop to call fix_env(). Provided this was correct how I've
done it, it doesn't fix my problem.

It's also not dependent on the webbrowser or different vs. same params
on subsequent request. The second and further requests just have an
empty parameter hash. A lighttpd restart is required to get it working
for one time again.

Regards,
Kai

I think I found the problem:

>
> >  I also had many problems with fcgi and lighttpd mainly because it was setting
> on subsequent request. The second and further requests just have an
> empty parameter hash. A lighttpd restart is required to get it working
> for one time again.

The problem seems to be that ruby's FCGI class clears the param hash
but doesn't reparse the query string upon next request. In my case
cgi.params just ends up empty. Since I didn't yet fully understand how
the FCGI class works and extends the CGI class, I just patched
Derrick's dispatcher:

@ about line 30
  def getBinding(cgi,env)
+   cgi.params = CGI::parse env["QUERY_STRING"]
    return binding
  end

This makes updating the cgi instance before the binding for the eval
is returned. I'm not sure if this is a valid fix but it work's in my
case. Also I am not sure if it is a wanted behaviour of class FCGI to
not reparse the query string in the FCGI.each_cgi loop.

So this is in my case fixed/hacked/whatever.