lighty 1.5 not passing QUERY_STRING to fast-cgi

I'm using mod_proxy_core to run some fast-cgi apps, but I'm
having  
problems with the QUERY_STRING env variable, which is not
being passed  
to the application...
Also, somewhere in the docs of fast-cgi, it is specified
that if I  
want to change the http status, I must set a Status header,
which will  
be read by the mod_fcgi (apache) and will change the http
status... is  
this the expected behaviour in lighty? if so, it's also not
working in  
1.5.


Regards,

-- 
Rolando Abarca
Phone: +56-9 97851962

On 2007-11-28 13:48:59 -0300, Rolando Abarca wrote:
> I'm using mod_proxy_core to run some fast-cgi apps, but
I'm having  
> problems with the QUERY_STRING env variable, which is
not being passed  
> to the application...

works for me

> Also, somewhere in the docs of fast-cgi, it is
specified that if I  
> want to change the http status, I must set a Status
header, which will  
> be read by the mod_fcgi (apache) and will change the
http status... is  
> this the expected behaviour in lighty? if so, it's also
not working in  
> 1.5.

works for me.

    darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org

first of all reply to the list. do not to mail me directly
all the time.

CCing the list again

On 2007-11-28 14:26:09 -0300, Rolando Abarca wrote:
> ...
> then it must be the ruby-fcgi implementation, the weird
thing is, that  
> the ruby fcgi works just fine with Apache 2...

actually i tested with my simple env.rb ruby-fcgi script

[[[
#!/usr/bin/ruby

require 'fcgi'
#
FCGI.each { |request|
  request.out.print "Status: 402 Payment
Requiredrn"
  request.out.print "Content-Type:
text/plainrnrn"
  request.out.print " Request Envn"
  request.out.print "=============nn"
  request.env.each do |k,v|
    request.out.printf "%20s => %sn", k, v
  end
  request.out.print "n"
  request.out.print "Source Coden"
  request.out.print "=============nn[[[n"
  File.open(__FILE__) do |f|
    request.out.print f.read
  end
  request.out.print "n]]]n"
  request.finish
}

]]]

[[[
curl -vsS http://local
host/fcgi-bin/env.rb?foo=bar
[snip]
> GET /fcgi-bin/env.rb?foo=bar HTTP/1.1
[snip]
< HTTP/1.1 402 Payment Required
< Content-Type: text/plain
[snip]
        QUERY_STRING => foo=bar
[snip]
]]]

looks fine to me though

    darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org

On Nov 28, 2007, at 2:42 PM, Marcus Rueckert wrote:

> first of all reply to the list. do not to mail me
directly all the  
> time.

sorry... missed the "reply all" button 

> CCing the list again
>
> On 2007-11-28 14:26:09 -0300, Rolando Abarca wrote:
>> ...
>> then it must be the ruby-fcgi implementation, the
weird thing is,  
>> that
>> the ruby fcgi works just fine with Apache 2...
>
> actually i tested with my simple env.rb ruby-fcgi
script
>
> [[[
> #!/usr/bin/ruby
>
> require 'fcgi'
> #
> FCGI.each { |request|
>  request.out.print "Status: 402 Payment
Requiredrn"
>  request.out.print "Content-Type:
text/plainrnrn"
>  request.out.print " Request Envn"
>  request.out.print "=============nn"
>  request.env.each do |k,v|
>    request.out.printf "%20s => %sn", k,
v
>  end
>  request.out.print "n"
>  request.out.print "Source Coden"
>  request.out.print "=============nn[[[n"
>  File.open(__FILE__) do |f|
>    request.out.print f.read
>  end
>  request.out.print "n]]]n"
>  request.finish
> }
>
> ]]]

yep. That worked for me also... Guess somehow I'm erasing
the  
QUERY_STRING env variable in the code.
thanks for the reply 

regards,
-- 
Rolando Abarca
Phone: +56-9 97851962

On 2007-11-28 14:45 -0300 (Wed), Rolando Abarca wrote:

> then it must be the ruby-fcgi implementation, the weird
thing is, that  
> the ruby fcgi works just fine with Apache 2...

If you're talking about the pure Ruby one most recently
maintained by
Minero Aoki, I doubt it; you've probably simply not
triggered the bugs.
In version 0.8.5 (the latest I've ever seen) you can make it
respond
properly to a signal when it's received, rather than waiting
for the
next request, by adding "select([server])" as the first
line of the
"session" method. I've not bothered to really get
into fixing the other
various issues I've encountered because they aren't frequent
and painful
enough to force a rewrite (and the current code is, IMHO,
overly complex
and obscure).

cjs
-- 
Curt Sampson       <cjsstarling-software.com>  
     +81 90 7737 2974   
Starling Software     <office-adminstarling-software.com>
Mobile sites and software consulting: http://www.starling-
software.com