[Chicken-users] Spiffy FastCGI Support

[Andy Bennett]

Hi,

Attached is a patch to the spiffy egg (as per 'chicken-install -r
spiffy' just now) which adds a FastCGI handler.

This allows Spiffy to use third party FastCGI scripts to generate responses.

Here's how you'd use it in a program:

Repsonder (Like a regular CGI script):
-----
(use fcgi-handler)
(fcgi-register-application 'testr fcgi-responder "examples/echo"
"/tmp/socketr" 2 2)
-----

Then in a request router:
-----
(... (lambda (continue) (fcgi-handler 'testr)))
-----



Authorizer (Returns a body to the client if auth fails otherwise just
returns some variables):
-----
(use fcgi-handler)
(fcgi-register-application 'testa fcgi-authorizer "examples/authorizer"
"/tmp/socketa" 2 2)
-----

Then in a request router or handler:

-----
(use spiffy)
(... (lambda (continue)
 (fcgi-handler 'testa continue: (lambda (x) (send-status 'ok x)))))
-----

If authorisation is successful then the argument to continue: is called
with an alist of variables that the Authorizer produced. These variables
usually tell you who was authorized.
The argument to continue: is expected to produce a response for the client.
If the authorisation fails then the Authorizer sends its own response
and the argument to continue: is not called.





This is an initial patch for review and testing. It has a number of
shortcomings:

 + The module currently exports everything.

 + Currently only FastCGI Responder and Authorizer roles are
implemented. I have no need for the Filter role so do not intend to
implement it.

 + There isn't much in the way of process management.
     SIGTERM will propagate to the FastCGI scripts that the handler
starts so they should usually exit with spiffy. However, spiffy doesn't
check that they actually start properly, nor does it manage the socket
files, so you'll have to remove those by hand each time you restart the
server.

 + Only Unix Domain Sockets are support: TCP/IP sockets cannot be used
to communicate between spiffy and the FastCGI script.
     Furthermore, fcgi-handler expects to start the FastCGI scripts and
pass them their socket: there is no support for out-of-band process
management.

 + The handler can spawn a number of processes for each handler at startup.
     If these processes crash then that's too bad: some requests will
get 500 errors. I've not tried it with PHP but it is generally advised
to only use PHP processes for a few requests and then to throw them away
and spawn new ones. The code in the patch does not do this.

 + There is provision in the API for the number of processes to spawn at
startup as well as the maximum number of process to allow. These numbers
must currently be equal.

 + The idea is to choose one of the processes for the given handler at
random and if it is busy to move onto another one. Due to a limitation
with the srfi-18 mutex code, the current algorithm chooses a random
process and then waits for it to be free before servicing that
particular request. (fcgi-handler.scm:878)

 + There is provision for statistics but this is not currently implemented.

 + Due to limitations in the POSIX unit we have our own fork-exec
implementation in C so that we can fork then exec without worrying about
another srfi-18 thread being scheduled in the child before the exec occurs.

 + There is no test suite.
     I've been using it here and have tested it with some of the
examples from the FCGI reference distribution as well as the FCGI
scripts I intent to use in production.

 + We strip out Content-Length headers that the handler sends us in its
replies and ensure the HTTP connection is closed.
     This is based on spiffy's CGI Handler logic to ensure the webserver
keeps its contract with the client in spite of badly behaved FastCGI
scripts.

 + There's no differentiation between idempotent and non-idempotent HTTP
requests.
     We assume the client always supplies content length for requests
with payloads but the CGI spec requires us to calculate it or return an
error if it was not supplied.

 + There is no documentation on the wiki.

 + There are probably other bugs that I haven' uncovered yet!


Please try it out and let me know how you get on.



Regards,
@ndy

-- 
address@hidden
http://www.ashurst.eu.org/
0x7EBA75FF

spiffy-fastcgi-2012-08-25.patch
Description: Text Data