FastCGI External Servers

[Aredridel]

I've just been trying to make ruby work as an external FastCGI
process, rather than one spawned by the webserver.

I've got some hackish code (also at
http://www.rubygarden.org/ruby?FCGIExternalServer) that works, but
only with the pure-ruby version of fcgi-0.8.5

FCGI_PURE_RUBY=true; require 'fcgi'
require 'socket'
def handleConnection(request)
request.out.puts "Content-type: text/html"
request.out.print "\r\n"
request.out.puts "Hello World"
request.finish
end

socket = UNIXServer.new('/tmp/fcrb_socket')
class << socket
alias ldaccept :accept
def accept
[oldaccept, nil]
end
end

FCGI::Server.new(socket).each_request do |request|
Thread.start {handleConnection(request)}
end


Has anyone used the C version to do this? Is there an easier way?

Any suggestions for ways to make the API better? I don't mind putting
work into what might become a new version of fcgi, but I'd love to
avoid re-implementing the wheel.

Ari

 

[Dan Fitzpatrick]

I've just been trying to make ruby work as an external FastCGI
process, rather than one spawned by the webserver.

I've got some hackish code (also at
http://www.rubygarden.org/ruby?FCGIExternalServer) that works, but
only with the pure-ruby version of fcgi-0.8.5

FCGI_PURE_RUBY=true; require 'fcgi'
require 'socket'
def handleConnection(request)
request.out.puts "Content-type: text/html"
request.out.print "\r\n"
request.out.puts "Hello World"
request.finish
end

socket = UNIXServer.new('/tmp/fcrb_socket')
class << socket
alias ldaccept :accept
def accept
[oldaccept, nil]
end
end

FCGI::Server.new(socket).each_request do |request|
Thread.start {handleConnection(request)}
end


Has anyone used the C version to do this? Is there an easier way?

Any suggestions for ways to make the API better? I don't mind putting
work into what might become a new version of fcgi, but I'd love to
avoid re-implementing the wheel.

Ari

I am interested in this subject and have looked at scgi
<http://www.mems-exchange.org/software/scgi/> and mod_webware
<http://www.webwareforpython.org/Webware/WebKit/Docs/InstallGuide.html#mod-webkit>.
I have just been exploring these because I would like to have an
external ruby server as well. I would be interested in implementing one
of these for Ruby. I assume that in either case you could use the
existing Apache module and just implement the app server code in Ruby/C.
Another option (I think) is building drb module for Apache that would
communicate with a ruby server via drb. Maybe you could even use
mod_ruby to do the drb communication. The mod_ruby script would be
relatively static. All application changes would be done on the ruby app
server. If you are interested in working on any of these (or something
similar) let me know. I'd like to build it this month. However I am new
to Ruby so am a little slow at it now - still spending a lot of time in
the reference docs.

Dan

 

[Aredridel]

I am interested in this subject and have looked at scgi

<http://www.mems-exchange.org/software/scgi/> and mod_webware
<http://www.webwareforpython.org/Webware/WebKit/Docs/InstallGuide.html#mod-webkit>.
I have just been exploring these because I would like to have an
external ruby server as well. I would be interested in implementing one
of these for Ruby. I assume that in either case you could use the
existing Apache module and just implement the app server code in Ruby/C.
Another option (I think) is building drb module for Apache that would
communicate with a ruby server via drb. Maybe you could even use
mod_ruby to do the drb communication. The mod_ruby script would be
relatively static. All application changes would be done on the ruby app
server. If you are interested in working on any of these (or something
similar) let me know. I'd like to build it this month. However I am new
to Ruby so am a little slow at it now - still spending a lot of time in
the reference docs.

Part of my problem is that I want a semi-standard protocol, not a
webserver module: I want to be free to lose Apache if I so desire. (And
I do; I'm an avid lighttpd user)

In that respect, SCGI could be a good option. However, SCGI looks like
FastCGI dumbed down a lot. That's not all bad, but it's still inheriting
a ton of cruft from CGI[1], and is even less standard than FCGI.

Ari

[1] Cruft like all-caps versions of HTTP headers, and various mangling
of important request data.