FastCGI

This specification has narrow goal is to specify, from an application perspective, the interface between a FastCGI application and a Web server that supports FastCGI. 4. Management Record Types 4.1 FCGI GET VALUES, FCGI GET VALUES RESULT FastCGI is an open extension to CGI that provides high performance for all Internet applications without the penalties of Web server APIs. This specification has narrow goal: to specify, from an application perspective, the interface between a FastCGI application and a Web server that supports FastCGI. Many Web server features related to FastCGI, e.g. application management facilities, have nothing to do with the application to Web server interface, and are not described here. This specification is for Unix (more precisely, for POSIX systems that support Berkeley Sockets). The bulk of the specification is a simple communications protocol that is independent of byte ordering and will extend to other systems. The initial state of a FastCGI process is more spartan than the initial state of a CGI/1.1 process, because the FastCGI process doesn’t begin life connected to anything. It doesn’t have the conventional open files stdin, stdout, and stderr, and it doesn’t receive much information through environment variables. The key piece of initial state in a FastCGI process is a listening socket, through which it accepts connections from a Web server. After a FastCGI process accepts a connection on its listening socket, the process executes a simple protocol to receive and send data. The protocol serves two purposes. First, the protocol multiplexes a single transport connection between several independent FastCGI requests. This supports applications that are able to process concurrent requests using event-driven or multi-threaded programming techniques. Second, within each request the protocol provides several independent data streams in each direction. This way, for instance, both stdout and stderr data pass over a single transport connection from the application to the Web server, rather than requiring separate pipes as with CGI/1.1. A FastCGI application plays one of several well-defined roles . The most familiar is the Responder role, in which the application receives all the information associated with an HTTP request and generates an HTTP response; that’s the role CGI/1.1 programs play. A second role is Authorizer , in which the application receives all the information associated with an HTTP request and generates an authorized/unauthorized decision. A third role is Filter , in which the application receives all the information associated with an HTTP request, plus an extra stream of data from a file stored on the Web server, and generates a “filtered” version of the data stream as an HTTP response. The framework is extensible so that more FastCGI can be defined later. In the remainder of this specification the terms “FastCGI application,” “application process,” or “application server” are abbreviated to “application” whenever that won’t cause confusion. By default the Web server creates an argument list containing a single element, the name of the application, taken to be the last component of the executable’s path name. The Web server may provide a way to specify a different application name, or a more elaborate argument list. Note that the file executed by the Web server might be an interpreter file (a text file that starts with the characters !), in which case the application’s argument list is constructed as described in the execve manpage. The Web server leaves a single file descriptor, FCGI LISTENSOCK FILENO, open when the application begins execution. This descriptor refers to a listening socket created by the Web server. FCGI LISTENSOCK FILENO equals STDIN FILENO. The standard descriptors STDOUT FILENO and STDERR FILENO are closed when the application begins execution. A reliable method for an application to determine whether it was invoked using CGI or FastCGI is to call getp