fastcgi event specification

Felix Gallo (
Thu, 9 May 1996 16:34:30 -0500 (CDT)

From: Felix Gallo <>
Message-Id: <>
Subject: fastcgi event specification
Date: Thu, 9 May 1996 16:34:30 -0500 (CDT)

For those of us not using libfcgi (for instance, those of us writing
a fastcgi interface in a language other than c), the spec seems a little
vague.  Here's the sequence of events I've gleaned from the docs and
the source code.

1.  The server receives a request.

2.  The server figures out which socket to start a transaction over.

    Unresolved: how does it do this, especially in light of the
    'affinity' concept?  What happens if you have more CGIs than
    your operating system permits for one process to have open
    streams or file descriptors (e.g., under Linux, FOPEN_MAX is 256,
    but POSIX minimum STREAM_MAX appears to be a paltry 16)?  Why
    are unix domain sockets (not existent in several very popular
    SVR3 Unix variants, such as SCO 3.x.x) included but named pipes not?

3.  The server opens a listening socket file descriptor, closes
all the rest of its file descriptors, and sets up, forks and execs
a fastcgi application.

    Unresolved: may a server ever call connect before forking?

4.  The server connects to the application.

    Unresolved: how does the application have any idea what servers
    are permitted to connect to that application?  Wouldn't this be
    a good use of the otherwise-avoided environment variables?

5.  The server sends the application a FCGI_BEGIN_REQUEST packet.

    Unresolved: how is the server supposed to have any idea what
    role the application is meant to play?  What behaviors occur
    if the application plays a different role from the expected
    role?  Wouldn't it make more sense for the application to
    provide the server with the possible roles it can play before
    the server sets policy?

6.  The server sends a bunch of name/value pairs via FCGI_PARAMS
to the application.

    Unresolved: why not set these in the environment as per
    'regular cgi' before the fork?  Surely the sets are faster
    than the protocol, and surely the params are going to be
    passed in 99% of the cases.

7.  The server and application happily mediate, perhaps even 
interleaving requests.

    Unresolved: is the ability to handle interleaved requests
    required of the application?  Can the application demand
    that it not be given interleaved requests?  What methods
    does the application use to signal to the server what
    behaviors can be expected of it?

8.  Depending on the server's expectation and the progress of the
transaction, the server or the application 'close the connection'
(terminate, however temporarily, the discussion).

    Unresolved: are the server or the application ever permitted
    to use the close system call on their respective ends of the
    filehandle?  If so, must the application attempt to return to
    a state where the server can make a connection using the same
    information the server had when it created the LISTEN socket?

Remaining unresolved issues and questions:

What behaviors are truly mandatory for every conformant implementation
of a fastcgi-aware application?

Why doesn't the name/value pair protocol use a single fixed-length
(4/4) header instead of requiring implementations to use byte-at-
a time reading, comparison, shifting and branching to determine
which header style is in use?  Given the the value length is
probably not going be near 4294967296 bytes on any box, why '4' besides
word alignment, and is transmitting that extra byte or two really
worth it?

Just another perl hacker,