FastCGI implementation in OCaml
anil.recoil.org
1<!DOCTYPE html>
2<html lang="en-us">
3 <head>
4 <meta charset="UTF-8">
5 <title>FastCGI Specification</title>
6 <meta name="description" content="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."/>
7 <meta name="keywords" content="fastcgi, fastcgi specification, fastcgi source, fastcgi php, fastcgi apache, fastcgi iis, fastcgi c++, fastcgi nginx, fastcgi download, fcgi spec, fcgi-spec, fastcgi overview, cgi, protocol specification, php-fpm, apache, mod_proxy_fastcgi, mod_fcgid, mod_fastcgi, fcgi2, fcgi sdk, nginx fastcgi, ngx_http_fastcgi_module, ligthttpd, cherokee, perl, python, ruby"/>
8 <meta name="viewport" content="width=device-width, initial-scale=1">
9 <meta name="theme-color" content="#157878">
10 <link href='https://fonts.googleapis.com/css?family=Open+Sans:400,700' rel='stylesheet' type='text/css'>
11 <link rel="stylesheet" href="/assets/css/style.css?v=cfbb93ce861c9fb058b2d12ee0a83e55a1682c1f">
12 </head>
13 <body>
14 <section class="page-header">
15 <h1 class="project-name">FastCGI Specification</h1>
16 <h2 class="project-tagline">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.</h2>
17
18 <a href="https://github.com/FastCGI-Archives" class="btn">View on GitHub</a>
19
20 </section>
21
22 <section class="main-content">
23 <p><a href="https://www.linkedin.com/in/mark-brown-32a01b11/">Mark R. Brown</a></p>
24
25<p>Open Market, Inc.</p>
26
27<p>Document Version: 1.0<br />
2829 April 1996</p>
29
30<h5 id="copyright--1996-open-market-inc-245-first-street-cambridge-ma-02142-usa">Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.</h5>
31
32<hr />
33
34<ul>
35 <li><a href="#S1">1. Introduction</a></li>
36 <li><a href="#S2">2. Initial Process State</a>
37 <ul>
38 <li><a href="#S2.1">2.1 Argument list</a></li>
39 <li><a href="#S2.2">2.2 File descriptors</a></li>
40 <li><a href="#S2.3">2.3 Environment variables</a></li>
41 <li><a href="#S2.4">2.4 Other state</a></li>
42 </ul>
43 </li>
44 <li><a href="#S3">3. Protocol Basics</a>
45 <ul>
46 <li><a href="#S3.1">3.1 Notation</a></li>
47 <li><a href="#S3.2">3.2 Accepting Transport Connections</a></li>
48 <li><a href="#S3.3">3.3 Records</a></li>
49 <li><a href="#S3.4">3.4 Name-Value Pairs</a></li>
50 <li><a href="#S3.5">3.5 Closing Transport Connections</a></li>
51 </ul>
52 </li>
53 <li><a href="#S4">4. Management Record Types</a>
54 <ul>
55 <li><a href="#S4.1">4.1 <tt>FCGI_GET_VALUES, FCGI_GET_VALUES_RESULT</tt></a></li>
56 <li><a href="#S4.2">4.2 <tt>FCGI_UNKNOWN_TYPE</tt></a></li>
57 </ul>
58 </li>
59 <li><a href="#S5">5. Application Record Types</a>
60 <ul>
61 <li><a href="#S5.1">5.1 <tt>FCGI_BEGIN_REQUEST</tt></a></li>
62 <li><a href="#S5.2">5.2 Name-Value Pair Streams: <tt>FCGI_PARAMS</tt>, <tt>FCGI_RESULTS</tt></a></li>
63 <li><a href="#S5.3">5.3 Byte Streams: <tt>FCGI_STDIN</tt>, <tt>FCGI_DATA</tt>, <tt>FCGI_STDOUT</tt>, <tt>FCGI_STDERR</tt></a></li>
64 <li><a href="#S5.4">5.4 <tt>FCGI_ABORT_REQUEST</tt></a></li>
65 <li><a href="#S5.5">5.5 <tt>FCGI_END_REQUEST</tt></a></li>
66 </ul>
67 </li>
68 <li><a href="#S6">6. Roles</a>
69 <ul>
70 <li><a href="#S6.1">6.1 Role Protocols</a></li>
71 <li><a href="#S6.2">6.2 Responder</a></li>
72 <li><a href="#S6.3">6.3 Authorizer</a></li>
73 <li><a href="#S6.4">6.4 Filter</a></li>
74 </ul>
75 </li>
76 <li><a href="#S7">7. Errors</a></li>
77 <li><a href="#S8">8. Types and Constants</a></li>
78 <li><a href="#S9">9. References</a></li>
79 <li><a href="#SA">A. Table: Properties of the record types</a></li>
80 <li><a href="#SB">B. Typical Protocol Message Flow</a></li>
81</ul>
82
83<hr />
84
85<h3 id="1-introduction"><a name="S1">1. Introduction</a></h3>
86
87<p>FastCGI is an open extension to CGI that provides high performance for all Internet applications without the penalties of Web server APIs.</p>
88
89<p>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.</p>
90
91<p>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.</p>
92
93<p>We’ll introduce FastCGI by comparing it with conventional Unix implementations of CGI/1.1. FastCGI is designed to support long-lived application processes, i.e. <em>application servers</em>. That’s a major difference compared with conventional Unix implementations of CGI/1.1, which construct an application process, use it respond to one request, and have it exit.</p>
94
95<p>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 <tt>stdin</tt>, <tt>stdout</tt>, and <tt>stderr</tt>, 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.</p>
96
97<p>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 <tt>stdout</tt> and <tt>stderr</tt> data pass over a single transport connection from the application to the Web server, rather than requiring separate pipes as with CGI/1.1.</p>
98
99<p>A FastCGI application plays one of several well-defined <em>roles</em>. The most familiar is the <em>Responder</em> 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 <em>Authorizer</em>, in which the application receives all the information associated with an HTTP request and generates an authorized/unauthorized decision. A third role is <em>Filter</em>, 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.</p>
100
101<p>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.</p>
102
103<h3 id="2-initial-process-state"><a name="S2">2. Initial Process State</a></h3>
104
105<h4 id="21-argument-list"><a name="S2.1">2.1 Argument list</a></h4>
106
107<p>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.</p>
108
109<p>Note that the file executed by the Web server might be an interpreter file (a text file that starts with the characters <tt>#!</tt>), in which case the application’s argument list is constructed as described in the <tt>execve</tt> manpage.</p>
110
111<h4 id="22-file-descriptors"><a name="S2.2">2.2 File descriptors</a></h4>
112
113<p>The Web server leaves a single file descriptor, <tt>FCGI_LISTENSOCK_FILENO</tt>, open when the application begins execution. This descriptor refers to a listening socket created by the Web server.</p>
114
115<p><tt>FCGI_LISTENSOCK_FILENO</tt> equals <tt>STDIN_FILENO</tt>. The standard descriptors <tt>STDOUT_FILENO</tt> and <tt>STDERR_FILENO</tt> 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 <tt>getpeername(FCGI_LISTENSOCK_FILENO)</tt>, which returns -1 with <tt>errno</tt> set to <tt>ENOTCONN</tt> for a FastCGI application.</p>
116
117<p>The Web server’s choice of reliable transport, Unix stream pipes (<tt>AF_UNIX</tt>) or TCP/IP (<tt>AF_INET</tt>), is implicit in the internal state of the <tt>FCGI_LISTENSOCK_FILENO</tt> socket.</p>
118
119<h4 id="23-environment-variables"><a name="S2.3">2.3 Environment variables</a></h4>
120
121<p>The Web server may use environment variables to pass parameters to the application. This specification defines one such variable, <tt>FCGI_WEB_SERVER_ADDRS</tt>; we expect more to be defined as the specification evolves. The Web server may provide a way to bind other environment variables, such as the <tt>PATH</tt> variable.</p>
122
123<h4 id="24-other-state"><a name="S2.4">2.4 Other state</a></h4>
124
125<p>The Web server may provide a way to specify other components of an application’s initial process state, such as the priority, user ID, group ID, root directory, and working directory of the process.</p>
126
127<h3 id="3-protocol-basics"><a name="S3">3. Protocol Basics</a></h3>
128
129<h4 id="31-notation"><a name="S3.1">3.1 Notation</a></h4>
130
131<p>We use C language notation to define protocol message formats. All structure elements are defined in terms of the <tt>unsigned char</tt> type, and are arranged so that an ISO C compiler lays them out in the obvious manner, with no padding. The first byte defined in the structure is transmitted first, the second byte second, etc.</p>
132
133<p>We use two conventions to abbreviate our definitions.</p>
134
135<p>First, when two adjacent structure components are named identically except for the suffixes “<tt>B1</tt>” and “<tt>B0</tt>,” it means that the two components may be viewed as a single number, computed as <tt>B1«8 + B0</tt>. The name of this single number is the name of the components, minus the suffixes. This convention generalizes in an obvious way to handle numbers represented in more than two bytes.</p>
136
137<p>Second, we extend C <tt>struct</tt>s to allow the form</p>
138
139<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> struct {
140 unsigned char mumbleLengthB1;
141 unsigned char mumbleLengthB0;
142 ... /* other stuff */
143 unsigned char mumbleData[mumbleLength];
144 };
145</code></pre></div></div>
146
147<p>meaning a structure of varying length, where the length of a component is determined by the values of the indicated earlier component or components.</p>
148
149<h4 id="32-accepting-transport-connections"><a name="S3.2">3.2 Accepting Transport Connections</a></h4>
150
151<p>A FastCGI application calls <tt>accept()</tt> on the socket referred to by file descriptor <tt>FCGI_LISTENSOCK_FILENO</tt> to accept a new transport connection. If the <tt>accept()</tt> succeeds, and the <tt>FCGI_WEB_SERVER_ADDRS</tt> environment variable is bound, the application application immediately performs the following special processing:</p>
152
153<ul>
154 <li>
155 <p><tt>FCGI_WEB_SERVER_ADDRS</tt>: The value is a list of valid IP addresses for the Web server.</p>
156
157 <p>If <tt>FCGI_WEB_SERVER_ADDRS</tt> was bound, the application checks the peer IP address of the new connection for membership in the list. If the check fails (including the possibility that the connection didn’t use TCP/IP transport), the application responds by closing the connection.</p>
158
159 <p><tt>FCGI_WEB_SERVER_ADDRS</tt> is expressed as a comma-separated list of IP addresses. Each IP address is written as four decimal numbers in the range [0..255] separated by decimal points. So one legal binding for this variable is <tt>FCGI_WEB_SERVER_ADDRS=199.170.183.28,199.170.183.71</tt>.</p>
160 </li>
161</ul>
162
163<p>An application may accept several concurrent transport connections, but it need not do so.</p>
164
165<h4 id="33-records"><a name="S3.3">3.3 Records</a></h4>
166
167<p>Applications execute requests from a Web server using a simple protocol. Details of the protocol depend upon the application’s role, but roughly speaking the Web server first sends parameters and other data to the application, then the application sends result data to the Web server, and finally the application sends the Web server an indication that the request is complete.</p>
168
169<p>All data that flows over the transport connection is carried in <em>FastCGI records</em>. FastCGI records accomplish two things. First, records multiplex the transport connection between several independent FastCGI requests. This multiplexing supports applications that are able to process concurrent requests using event-driven or multi-threaded programming techniques. Second, records provide several independent data streams in each direction within a single request. This way, for instance, both <tt>stdout</tt> and <tt>stderr</tt> data can pass over a single transport connection from the application to the Web server, rather than requiring separate connections.</p>
170
171<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> typedef struct {
172 unsigned char version;
173 unsigned char type;
174 unsigned char requestIdB1;
175 unsigned char requestIdB0;
176 unsigned char contentLengthB1;
177 unsigned char contentLengthB0;
178 unsigned char paddingLength;
179 unsigned char reserved;
180 unsigned char contentData[contentLength];
181 unsigned char paddingData[paddingLength];
182 } FCGI_Record;
183</code></pre></div></div>
184
185<p>A FastCGI record consists of a fixed-length prefix followed by a variable number of content and padding bytes. A record contains seven components:</p>
186
187<ul>
188 <li><tt>version</tt>: Identifies the FastCGI protocol version. This specification documents <tt>FCGI_VERSION_1</tt>.</li>
189 <li><tt>type</tt>: Identifies the FastCGI record type, i.e. the general function that the record performs. Specific record types and their functions are detailed in later sections.</li>
190 <li><tt>requestId</tt>: Identifies the <em>FastCGI request</em> to which the record belongs.</li>
191 <li><tt>contentLength</tt>: The number of bytes in the <tt>contentData</tt> component of the record.</li>
192 <li><tt>paddingLength</tt>: The number of bytes in the <tt>paddingData</tt> component of the record.</li>
193 <li><tt>contentData</tt>: Between 0 and 65535 bytes of data, interpreted according to the record type.</li>
194 <li><tt>paddingData</tt>: Between 0 and 255 bytes of data, which are ignored.</li>
195</ul>
196
197<p>We use a relaxed C <tt>struct</tt> initializer syntax to specify constant FastCGI records. We omit the <tt>version</tt> component, ignore padding, and treat <tt>requestId</tt> as a number. Thus <tt>{FCGI_END_REQUEST, 1, {FCGI_REQUEST_COMPLETE,0}}</tt> is a record with <tt>type == FCGI_END_REQUEST</tt>, <tt>requestId == 1</tt>, and <tt>contentData == {FCGI_REQUEST_COMPLETE,0}</tt>.</p>
198
199<h5 id="padding">Padding</h5>
200
201<p>The protocol allows senders to pad the records they send, and requires receivers to interpret the <tt>paddingLength</tt> and skip the <tt>paddingData</tt>. Padding allows senders to keep data aligned for more efficient processing. Experience with the X window system protocols shows the performance benefit of such alignment.</p>
202
203<p>We recommend that records be placed on boundaries that are multiples of eight bytes. The fixed-length portion of a <tt>FCGI_Record</tt> is eight bytes.</p>
204
205<h5 id="managing-request-ids">Managing Request IDs</h5>
206
207<p>The Web server re-uses FastCGI request IDs; the application keeps track of the current state of each request ID on a given transport connection. A request ID <tt>R</tt> becomes active when the application receives a record <tt>{FCGI_BEGIN_REQUEST, R, …}</tt> and becomes inactive when the application sends a record <tt>{FCGI_END_REQUEST, R, …}</tt> to the Web server.</p>
208
209<p>While a request ID <tt>R</tt> is inactive, the application ignores records with <tt>requestId == R</tt>, except for <tt>FCGI_BEGIN_REQUEST</tt> records as just described.</p>
210
211<p>The Web server attempts to keep FastCGI request IDs small. That way the application can keep track of request ID states using a short array rather than a long array or a hash table. An application also has the option of accepting only one request at a time. In this case the application simply checks incoming <tt>requestId</tt> values against the current request ID.</p>
212
213<h5 id="types-of-record-types">Types of Record Types</h5>
214
215<p>There are two useful ways of classifying FastCGI record types.</p>
216
217<p>The first distinction is between <em>management</em> records and <em>application</em> records. A management record contains information that is not specific to any Web server request, such as information about the protocol capabilities of the application. An application record contains information about a particular request, identified by the <tt>requestId</tt> component.</p>
218
219<p>Management records have a <tt>requestId</tt> value of zero, also called the <em>null request ID</em>. Application records have a nonzero <tt>requestId</tt>.</p>
220
221<p>The second distinction is between <em>discrete</em> and <em>stream</em> records. A discrete record contains a meaningful unit of data all by itself. A stream record is part of a <em>stream</em>, i.e. a series of zero or more non-empty records (<tt>length != 0</tt>) of the stream type, followed by an empty record (<tt>length == 0</tt>) of the stream type. The <tt>contentData</tt> components of a stream’s records, when concatenated, form a byte sequence; this byte sequence is the value of the stream. Therefore the value of a stream is independent of how many records it contains or how its bytes are divided among the non-empty records.</p>
222
223<p>These two classifications are independent. Among the record types defined in this version of the FastCGI protocol, all management record types are also discrete record types, and nearly all application record types are stream record types. But three application record types are discrete, and nothing prevents defining a management record type that’s a stream in some later version of the protocol.</p>
224
225<h4 id="34-name-value-pairs"><a name="S3.4">3.4 Name-Value Pairs</a></h4>
226
227<p>In many of their roles, FastCGI applications need to read and write varying numbers of variable-length values. So it is useful to adopt a standard format for encoding a name-value pair.</p>
228
229<p>FastCGI transmits a name-value pair as the length of the name, followed by the length of the value, followed by the name, followed by the value. Lengths of 127 bytes and less can be encoded in one byte, while longer lengths are always encoded in four bytes:</p>
230
231<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> typedef struct {
232 unsigned char nameLengthB0; /* nameLengthB0 >> 7 == 0 */
233 unsigned char valueLengthB0; /* valueLengthB0 >> 7 == 0 */
234 unsigned char nameData[nameLength];
235 unsigned char valueData[valueLength];
236 } FCGI_NameValuePair11;
237
238 typedef struct {
239 unsigned char nameLengthB0; /* nameLengthB0 >> 7 == 0 */
240 unsigned char valueLengthB3; /* valueLengthB3 >> 7 == 1 */
241 unsigned char valueLengthB2;
242 unsigned char valueLengthB1;
243 unsigned char valueLengthB0;
244 unsigned char nameData[nameLength];
245 unsigned char valueData[valueLength
246 ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
247 } FCGI_NameValuePair14;
248
249 typedef struct {
250 unsigned char nameLengthB3; /* nameLengthB3 >> 7 == 1 */
251 unsigned char nameLengthB2;
252 unsigned char nameLengthB1;
253 unsigned char nameLengthB0;
254 unsigned char valueLengthB0; /* valueLengthB0 >> 7 == 0 */
255 unsigned char nameData[nameLength
256 ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
257 unsigned char valueData[valueLength];
258 } FCGI_NameValuePair41;
259
260 typedef struct {
261 unsigned char nameLengthB3; /* nameLengthB3 >> 7 == 1 */
262 unsigned char nameLengthB2;
263 unsigned char nameLengthB1;
264 unsigned char nameLengthB0;
265 unsigned char valueLengthB3; /* valueLengthB3 >> 7 == 1 */
266 unsigned char valueLengthB2;
267 unsigned char valueLengthB1;
268 unsigned char valueLengthB0;
269 unsigned char nameData[nameLength
270 ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
271 unsigned char valueData[valueLength
272 ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
273 } FCGI_NameValuePair44;
274</code></pre></div></div>
275
276<p>The high-order bit of the first byte of a length indicates the length’s encoding. A high-order zero implies a one-byte encoding, a one a four-byte encoding.</p>
277
278<p>This name-value pair format allows the sender to transmit binary values without additional encoding, and enables the receiver to allocate the correct amount of storage immediately even for large values.</p>
279
280<h4 id="35-closing-transport-connections"><a name="S3.5">3.5 Closing Transport Connections</a></h4>
281
282<p>The Web server controls the lifetime of transport connections. The Web server can close a connection when no requests are active. Or the Web server can delegate close authority to the application (see <tt>FCGI_BEGIN_REQUEST</tt>). In this case the application closes the connection at the end of a specified request.</p>
283
284<p>This flexibility accommodates a variety of application styles. Simple applications will process one request at a time and accept a new transport connection for each request. More complex applications will process concurrent requests, over one or multiple transport connections, and will keep transport connections open for long periods of time.</p>
285
286<p>A simple application gets a significant performance boost by closing the transport connection when it has finished writing its response. The Web server needs to control the connection lifetime for long-lived connections.</p>
287
288<p>When an application closes a connection or finds that a connection has closed, the application initiates a new connection.</p>
289
290<h3 id="4-management-record-types"><a name="S4">4. Management Record Types</a></h3>
291
292<h4 id="41-fcgi_get_values-fcgi_get_values_result"><a name="S4.1">4.1 <tt>FCGI_GET_VALUES, FCGI_GET_VALUES_RESULT</tt></a></h4>
293
294<p>The Web server can query specific variables within the application. The server will typically perform a query on application startup in order to to automate certain aspects of system configuration.</p>
295
296<p>The application receives a query as a record <tt>{FCGI_GET_VALUES, 0, …}</tt>. The <tt>contentData</tt> portion of a <tt>FCGI_GET_VALUES</tt> record contains a sequence of name-value pairs with empty values.</p>
297
298<p>The application responds by sending a record <tt>{FCGI_GET_VALUES_RESULT, 0, …}</tt> with the values supplied. If the application doesn’t understand a variable name that was included in the query, it omits that name from the response.</p>
299
300<p><tt>FCGI_GET_VALUES</tt> is designed to allow an open-ended set of variables. The initial set provides information to help the server perform application and connection management:</p>
301
302<ul>
303 <li><tt>FCGI_MAX_CONNS</tt>: The maximum number of concurrent transport connections this application will accept, e.g. <tt>“1”</tt> or <tt>“10”</tt>.</li>
304 <li><tt>FCGI_MAX_REQS</tt>: The maximum number of concurrent requests this application will accept, e.g. <tt>“1”</tt> or <tt>“50”</tt>.</li>
305 <li><tt>FCGI_MPXS_CONNS</tt>: <tt>“0”</tt> if this application does not multiplex connections (i.e. handle concurrent requests over each connection), <tt>“1”</tt> otherwise.</li>
306</ul>
307
308<p>An application may receive a <tt>FCGI_GET_VALUES</tt> record at any time. The application’s response should not involve the application proper but only the FastCGI library.</p>
309
310<h4 id="42-fcgi_unknown_type"><a name="S4.2">4.2 <tt>FCGI_UNKNOWN_TYPE</tt></a></h4>
311
312<p>The set of management record types is likely to grow in future versions of this protocol. To provide for this evolution, the protocol includes the <tt>FCGI_UNKNOWN_TYPE</tt> management record. When an application receives a management record whose type <tt>T</tt> it does not understand, the application responds with <tt>{FCGI_UNKNOWN_TYPE, 0, {T}}</tt>.</p>
313
314<p>The <tt>contentData</tt> component of a <tt>FCGI_UNKNOWN_TYPE</tt> record has the form:</p>
315
316<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> typedef struct {
317 unsigned char type;
318 unsigned char reserved[7];
319 } FCGI_UnknownTypeBody;
320</code></pre></div></div>
321
322<p>The <tt>type</tt> component is the type of the unrecognized management record.</p>
323
324<h3 id="5-application-record-types"><a name="S5">5. Application Record Types</a></h3>
325
326<h4 id="51-fcgi_begin_request"><a name="S5.1">5.1 <tt>FCGI_BEGIN_REQUEST</tt></a></h4>
327
328<p>The Web server sends a <tt>FCGI_BEGIN_REQUEST</tt> record to start a request.</p>
329
330<p>The <tt>contentData</tt> component of a <tt>FCGI_BEGIN_REQUEST</tt> record has the form:</p>
331
332<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> typedef struct {
333 unsigned char roleB1;
334 unsigned char roleB0;
335 unsigned char flags;
336 unsigned char reserved[5];
337 } FCGI_BeginRequestBody;
338</code></pre></div></div>
339
340<p>The <tt>role</tt> component sets the role the Web server expects the application to play. The currently-defined roles are:</p>
341
342<ul>
343 <li><tt>FCGI_RESPONDER</tt></li>
344 <li><tt>FCGI_AUTHORIZER</tt></li>
345 <li><tt>FCGI_FILTER</tt></li>
346</ul>
347
348<p>Roles are described in more detail in <a href="#S6">Section 6</a> below.</p>
349
350<p>The <tt>flags</tt> component contains a bit that controls connection shutdown:</p>
351
352<ul>
353 <li><tt>flags & FCGI_KEEP_CONN</tt>: If zero, the application closes the connection after responding to this request. If not zero, the application does not close the connection after responding to this request; the Web server retains responsibility for the connection.</li>
354</ul>
355
356<h4 id="52-name-value-pair-stream-fcgi_params"><a name="S5.2">5.2 Name-Value Pair Stream: <tt>FCGI_PARAMS</tt></a></h4>
357
358<p><tt>FCGI_PARAMS</tt></p>
359
360<p>is a stream record type used in sending name-value pairs from the Web server to the application. The name-value pairs are sent down the stream one after the other, in no specified order.</p>
361
362<h4 id="53-byte-streams-fcgi_stdin-fcgi_data-fcgi_stdout-fcgi_stderr"><a name="S5.3">5.3 Byte Streams: <tt>FCGI_STDIN</tt>, <tt>FCGI_DATA</tt>, <tt>FCGI_STDOUT</tt>, <tt>FCGI_STDERR</tt></a></h4>
363
364<p><tt>FCGI_STDIN</tt></p>
365
366<p>is a stream record type used in sending arbitrary data from the Web server to the application. <tt>FCGI_DATA</tt> is a second stream record type used to send additional data to the application.</p>
367
368<p><tt>FCGI_STDOUT</tt> and <tt>FCGI_STDERR</tt> are stream record types for sending arbitrary data and error data respectively from the application to the Web server.</p>
369
370<h4 id="54-fcgi_abort_request"><a name="S5.4">5.4 <tt>FCGI_ABORT_REQUEST</tt></a></h4>
371
372<p>The Web server sends a <tt>FCGI_ABORT_REQUEST</tt> record to abort a request. After receiving <tt>{FCGI_ABORT_REQUEST, R}</tt>, the application responds as soon as possible with <tt>{FCGI_END_REQUEST, R, {FCGI_REQUEST_COMPLETE, appStatus}}</tt>. This is truly a response from the application, not a low-level acknowledgement from the FastCGI library.</p>
373
374<p>A Web server aborts a FastCGI request when an HTTP client closes its transport connection while the FastCGI request is running on behalf of that client. The situation may seem unlikely; most FastCGI requests will have short response times, with the Web server providing output buffering if the client is slow. But the FastCGI application may be delayed communicating with another system, or performing a server push.</p>
375
376<p>When a Web server is not multiplexing requests over a transport connection, the Web server can abort a request by closing the request’s transport connection. But with multiplexed requests, closing the transport connection has the unfortunate effect of aborting <em>all</em> the requests on the connection.</p>
377
378<h4 id="55-fcgi_end_request"><a name="S5.5">5.5 <tt>FCGI_END_REQUEST</tt></a></h4>
379
380<p>The application sends a <tt>FCGI_END_REQUEST</tt> record to terminate a request, either because the application has processed the request or because the application has rejected the request.</p>
381
382<p>The <tt>contentData</tt> component of a <tt>FCGI_END_REQUEST</tt> record has the form:</p>
383
384<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> typedef struct {
385 unsigned char appStatusB3;
386 unsigned char appStatusB2;
387 unsigned char appStatusB1;
388 unsigned char appStatusB0;
389 unsigned char protocolStatus;
390 unsigned char reserved[3];
391 } FCGI_EndRequestBody;
392</code></pre></div></div>
393
394<p>The <tt>appStatus</tt> component is an application-level status code. Each role documents its usage of <tt>appStatus</tt>.</p>
395
396<p>The <tt>protocolStatus</tt> component is a protocol-level status code; the possible <tt>protocolStatus</tt> values are:</p>
397
398<ul>
399 <li><tt>FCGI_REQUEST_COMPLETE</tt>: normal end of request.</li>
400 <li><tt>FCGI_CANT_MPX_CONN</tt>: rejecting a new request. This happens when a Web server sends concurrent requests over one connection to an application that is designed to process one request at a time per connection.</li>
401 <li><tt>FCGI_OVERLOADED</tt>: rejecting a new request. This happens when the application runs out of some resource, e.g. database connections.</li>
402 <li><tt>FCGI_UNKNOWN_ROLE</tt>: rejecting a new request. This happens when the Web server has specified a role that is unknown to the application.</li>
403</ul>
404
405<h3 id="6-roles"><a name="S6">6. Roles</a></h3>
406
407<h4 id="61-role-protocols"><a name="S6.1">6.1 Role Protocols</a></h4>
408
409<p>Role protocols only include records with application record types. They transfer essentially all data using streams.</p>
410
411<p>To make the protocols reliable and to simplify application programming, role protocols are designed to use <em>nearly sequential marshalling</em>. In a protocol with strictly sequential marshalling, the application receives its first input, then its second, etc. until it has received them all. Similarly, the application sends its first output, then its second, etc. until it has sent them all. Inputs are not interleaved with each other, and outputs are not interleaved with each other.</p>
412
413<p>The sequential marshalling rule is too restrictive for some FastCGI roles, because CGI programs can write to both <tt>stdout</tt> and <tt>stderr</tt> without timing restrictions. So role protocols that use both <tt>FCGI_STDOUT</tt> and <tt>FCGI_STDERR</tt> allow these two streams to be interleaved.</p>
414
415<p>All role protocols use the <tt>FCGI_STDERR</tt> stream just the way <tt>stderr</tt> is used in conventional applications programming: to report application-level errors in an intelligible way. Use of the <tt>FCGI_STDERR</tt> stream is always optional. If an application has no errors to report, it sends either no <tt>FCGI_STDERR</tt> records or one zero-length <tt>FCGI_STDERR</tt> record.</p>
416
417<p>When a role protocol calls for transmitting a stream other than <tt>FCGI_STDERR</tt>, at least one record of the stream type is always transmitted, even if the stream is empty.</p>
418
419<p>Again in the interests of reliable protocols and simplified application programming, role protocols are designed to be <em>nearly request-response</em>. In a truly request-response protocol, the application receives all of its input records before sending its first output record. Request-response protocols don’t allow pipelining.</p>
420
421<p>The request-response rule is too restrictive for some FastCGI roles; after all, CGI programs aren’t restricted to read all of <tt>stdin</tt> before starting to write <tt>stdout</tt>. So some role protocols allow that specific possibility. First the application receives all of its inputs except for a final stream input. As the application begins to receive the final stream input, it can begin writing its output.</p>
422
423<p>When a role protocol uses <tt>FCGI_PARAMS</tt> to transmit textual values, such as the values that CGI programs obtain from environment variables, the length of the value does not include the terminating null byte, and the value itself does not include a null byte. An application that needs to provide <tt>environ(7)</tt> format name-value pairs must insert an equal sign between the name and value and append a null byte after the value.</p>
424
425<p>Role protocols do not support the non-parsed header feature of CGI. FastCGI applications set response status using the <tt>Status</tt> and <tt>Location</tt> CGI headers.</p>
426
427<h4 id="62-responder"><a name="S6.2">6.2 Responder</a></h4>
428
429<p>A Responder FastCGI application has the same purpose as a CGI/1.1 program: It receives all the information associated with an HTTP request and generates an HTTP response.</p>
430
431<p>It suffices to explain how each element of CGI/1.1 is emulated by a Responder:</p>
432
433<ul>
434 <li>The Responder application receives CGI/1.1 environment variables from the Web server over <tt>FCGI_PARAMS</tt>.</li>
435 <li>Next the Responder application receives CGI/1.1 <tt>stdin</tt> data from the Web server over <tt>FCGI_STDIN</tt>. The application receives at most <tt>CONTENT_LENGTH</tt> bytes from this stream before receiving the end-of-stream indication. (The application receives less than <tt>CONTENT_LENGTH</tt> bytes only if the HTTP client fails to provide them, e.g. because the client crashed.)</li>
436 <li>The Responder application sends CGI/1.1 <tt>stdout</tt> data to the Web server over <tt>FCGI_STDOUT</tt>, and CGI/1.1 <tt>stderr</tt> data over <tt>FCGI_STDERR</tt>. The application sends these concurrently, not one after the other. The application must wait to finish reading <tt>FCGI_PARAMS</tt> before it begins writing <tt>FCGI_STDOUT</tt> and <tt>FCGI_STDERR</tt>, but it needn’t finish reading from <tt>FCGI_STDIN</tt> before it begins writing these two streams.</li>
437 <li>After sending all its <tt>stdout</tt> and <tt>stderr</tt> data, the Responder application sends a <tt>FCGI_END_REQUEST</tt> record. The application sets the <tt>protocolStatus</tt> component to <tt>FCGI_REQUEST_COMPLETE</tt> and the <tt>appStatus</tt> component to the status code that the CGI program would have returned via the <tt>exit</tt> system call.</li>
438</ul>
439
440<p>A Responder performing an update, e.g. implementing a <tt>POST</tt> method, should compare the number of bytes received on <tt>FCGI_STDIN</tt> with <tt>CONTENT_LENGTH</tt> and abort the update if the two numbers are not equal.</p>
441
442<h4 id="63-authorizer"><a name="S6.3">6.3 Authorizer</a></h4>
443
444<p>An Authorizer FastCGI application receives all the information associated with an HTTP request and generates an authorized/unauthorized decision. In case of an authorized decision the Authorizer can also associate name-value pairs with the HTTP request; when giving an unauthorized decision the Authorizer sends a complete response to the HTTP client.</p>
445
446<p>Since CGI/1.1 defines a perfectly good way to represent the information associated with an HTTP request, Authorizers use the same representation:</p>
447
448<ul>
449 <li>The Authorizer application receives HTTP request information from the Web server on the <tt>FCGI_PARAMS</tt> stream, in the same format as a Responder. The Web server does not send <tt>CONTENT_LENGTH</tt>, <tt>PATH_INFO</tt>, <tt>PATH_TRANSLATED</tt>, and <tt>SCRIPT_NAME</tt> headers.</li>
450 <li>
451 <p>The Authorizer application sends <tt>stdout</tt> and <tt>stderr</tt> data in the same manner as a Responder. The CGI/1.1 response status specifies the disposition of the request. If the application sends status 200 (OK), the Web server allows access. Depending upon its configuration the Web server may proceed with other access checks, including requests to other Authorizers.</p>
452
453 <p>An Authorizer application’s 200 response may include headers whose names are prefixed with <tt>Variable-</tt>. These headers communicate name-value pairs from the application to the Web server. For instance, the response header</p>
454
455 <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> Variable-AUTH_METHOD: database lookup
456</code></pre></div> </div>
457
458 <p>transmits the value <tt>“database lookup”</tt> with name <tt>AUTH-METHOD</tt>. The server associates such name-value pairs with the HTTP request and includes them in subsequent CGI or FastCGI requests performed in processing the HTTP request. When the application gives a 200 response, the server ignores response headers whose names aren’t prefixed with <tt>Variable-</tt> prefix, and ignores any response content.</p>
459
460 <p>For Authorizer response status values other than “200” (OK), the Web server denies access and sends the response status, headers, and content back to the HTTP client.</p>
461 </li>
462</ul>
463
464<h4 id="64-filter"><a name="S6.4">6.4 Filter</a></h4>
465
466<p>A Filter FastCGI 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.</p>
467
468<p>A Filter is similar in functionality to a Responder that takes a data file as a parameter. The difference is that with a Filter, both the data file and the Filter itself can be access controlled using the Web server’s access control mechanisms, while a Responder that takes the name of a data file as a parameter must perform its own access control checks on the data file.</p>
469
470<p>The steps taken by a Filter are similar to those of a Responder. The server presents the Filter with environment variables first, then standard input (normally form <tt>POST</tt> data), finally the data file input:</p>
471
472<ul>
473 <li>Like a Responder, the Filter application receives name-value pairs from the Web server over <tt>FCGI_PARAMS</tt>. Filter applications receive two Filter-specific variables: <tt>FCGI_DATA_LAST_MOD</tt> and <tt>FCGI_DATA_LENGTH</tt>.</li>
474 <li>Next the Filter application receives CGI/1.1 <tt>stdin</tt> data from the Web server over <tt>FCGI_STDIN</tt>. The application receives at most <tt>CONTENT_LENGTH</tt> bytes from this stream before receiving the end-of-stream indication. (The application receives less than <tt>CONTENT_LENGTH</tt> bytes only if the HTTP client fails to provide them, e.g. because the client crashed.)</li>
475 <li>Next the Filter application receives the file data from the Web server over <tt>FCGI_DATA</tt>. This file’s last modification time (expressed as an integer number of seconds since the epoch January 1, 1970 UTC) is <tt>FCGI_DATA_LAST_MOD</tt>; the application may consult this variable and respond from a cache without reading the file data. The application reads at most <tt>FCGI_DATA_LENGTH</tt> bytes from this stream before receiving the end-of-stream indication.</li>
476 <li>The Filter application sends CGI/1.1 <tt>stdout</tt> data to the Web server over <tt>FCGI_STDOUT</tt>, and CGI/1.1 <tt>stderr</tt> data over <tt>FCGI_STDERR</tt>. The application sends these concurrently, not one after the other. The application must wait to finish reading <tt>FCGI_STDIN</tt> before it begins writing <tt>FCGI_STDOUT</tt> and <tt>FCGI_STDERR</tt>, but it needn’t finish reading from <tt>FCGI_DATA</tt> before it begins writing these two streams.</li>
477 <li>After sending all its <tt>stdout</tt> and <tt>stderr</tt> data, the application sends a <tt>FCGI_END_REQUEST</tt> record. The application sets the <tt>protocolStatus</tt> component to <tt>FCGI_REQUEST_COMPLETE</tt> and the <tt>appStatus</tt> component to the status code that a similar CGI program would have returned via the <tt>exit</tt> system call.</li>
478</ul>
479
480<p>A Filter should compare the number of bytes received on <tt>FCGI_STDIN</tt> with <tt>CONTENT_LENGTH</tt> and on <tt>FCGI_DATA</tt> with <tt>FCGI_DATA_LENGTH</tt>. If the numbers don’t match and the Filter is a query, the Filter response should provide an indication that data is missing. If the numbers don’t match and the Filter is an update, the Filter should abort the update.</p>
481
482<h3 id="7-errors"><a name="S7">7. Errors</a></h3>
483
484<p>A FastCGI application exits with zero status to indicate that it terminated on purpose, e.g. in order to perform a crude form of garbage collection. A FastCGI application that exits with nonzero status is assumed to have crashed. How a Web server or other application manager responds to applications that exit with zero or nonzero status is outside the scope of this specification.</p>
485
486<p>A Web server can request that a FastCGI application exit by sending it <tt>SIGTERM</tt>. If the application ignores <tt>SIGTERM</tt> the Web server can resort to <tt>SIGKILL</tt>.</p>
487
488<p>FastCGI applications report application-level errors with the <tt>FCGI_STDERR</tt> stream and the <tt>appStatus</tt> component of the <tt>FCGI_END_REQUEST</tt> record. In many cases an error will be reported directly to the user via the <tt>FCGI_STDOUT</tt> stream.</p>
489
490<p>On Unix, applications report lower-level errors, including FastCGI protocol errors and syntax errors in FastCGI environment variables, to <tt>syslog</tt>. Depending upon the severity of the error, the application may either continue or exit with nonzero status.</p>
491
492<h3 id="8-types-and-constants"><a name="S8">8. Types and Constants</a></h3>
493
494<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/*
495 * Listening socket file number
496 */
497#define FCGI_LISTENSOCK_FILENO 0
498
499typedef struct {
500 unsigned char version;
501 unsigned char type;
502 unsigned char requestIdB1;
503 unsigned char requestIdB0;
504 unsigned char contentLengthB1;
505 unsigned char contentLengthB0;
506 unsigned char paddingLength;
507 unsigned char reserved;
508} FCGI_Header;
509
510/*
511 * Number of bytes in a FCGI_Header. Future versions of the protocol
512 * will not reduce this number.
513 */
514#define FCGI_HEADER_LEN 8
515
516/*
517 * Value for version component of FCGI_Header
518 */
519#define FCGI_VERSION_1 1
520
521/*
522 * Values for type component of FCGI_Header
523 */
524#define FCGI_BEGIN_REQUEST 1
525#define FCGI_ABORT_REQUEST 2
526#define FCGI_END_REQUEST 3
527#define FCGI_PARAMS 4
528#define FCGI_STDIN 5
529#define FCGI_STDOUT 6
530#define FCGI_STDERR 7
531#define FCGI_DATA 8
532#define FCGI_GET_VALUES 9
533#define FCGI_GET_VALUES_RESULT 10
534#define FCGI_UNKNOWN_TYPE 11
535#define FCGI_MAXTYPE (FCGI_UNKNOWN_TYPE)
536
537/*
538 * Value for requestId component of FCGI_Header
539 */
540#define FCGI_NULL_REQUEST_ID 0
541
542typedef struct {
543 unsigned char roleB1;
544 unsigned char roleB0;
545 unsigned char flags;
546 unsigned char reserved[5];
547} FCGI_BeginRequestBody;
548
549typedef struct {
550 FCGI_Header header;
551 FCGI_BeginRequestBody body;
552} FCGI_BeginRequestRecord;
553
554/*
555 * Mask for flags component of FCGI_BeginRequestBody
556 */
557#define FCGI_KEEP_CONN 1
558
559/*
560 * Values for role component of FCGI_BeginRequestBody
561 */
562#define FCGI_RESPONDER 1
563#define FCGI_AUTHORIZER 2
564#define FCGI_FILTER 3
565
566typedef struct {
567 unsigned char appStatusB3;
568 unsigned char appStatusB2;
569 unsigned char appStatusB1;
570 unsigned char appStatusB0;
571 unsigned char protocolStatus;
572 unsigned char reserved[3];
573} FCGI_EndRequestBody;
574
575typedef struct {
576 FCGI_Header header;
577 FCGI_EndRequestBody body;
578} FCGI_EndRequestRecord;
579
580/*
581 * Values for protocolStatus component of FCGI_EndRequestBody
582 */
583#define FCGI_REQUEST_COMPLETE 0
584#define FCGI_CANT_MPX_CONN 1
585#define FCGI_OVERLOADED 2
586#define FCGI_UNKNOWN_ROLE 3
587
588/*
589 * Variable names for FCGI_GET_VALUES / FCGI_GET_VALUES_RESULT records
590 */
591#define FCGI_MAX_CONNS "FCGI_MAX_CONNS"
592#define FCGI_MAX_REQS "FCGI_MAX_REQS"
593#define FCGI_MPXS_CONNS "FCGI_MPXS_CONNS"
594
595typedef struct {
596 unsigned char type;
597 unsigned char reserved[7];
598} FCGI_UnknownTypeBody;
599
600typedef struct {
601 FCGI_Header header;
602 FCGI_UnknownTypeBody body;
603} FCGI_UnknownTypeRecord;
604</code></pre></div></div>
605
606<h3 id="9-references"><a name="S9">9. References</a></h3>
607
608<p><a href="https://www.w3.org/CGI/">The WWW Common Gateway Interface at W3C</a></p>
609
610<h3 id="a-table-properties-of-the-record-types"><a name="SA">A. Table: Properties of the record types</a></h3>
611
612<p>The following chart lists all of the record types and indicates these properties of each:</p>
613
614<ul>
615 <li><tt>WS->App</tt>: records of this type can only be sent by the Web server to the application. Records of other types can only be sent by the application to the Web server.</li>
616 <li><tt>management</tt>: records of this type contain information that is not specific to a Web server request, and use the null request ID. Records of other types contain request-specific information, and cannot use the null request ID.</li>
617 <li><tt>stream</tt>: records of this type form a stream, terminated by a record with empty <tt>contentData</tt>. Records of other types are discrete; each carries a meaningful unit of data.</li>
618</ul>
619
620<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> WS->App management stream
621
622 FCGI_GET_VALUES x x
623 FCGI_GET_VALUES_RESULT x
624 FCGI_UNKNOWN_TYPE x
625
626 FCGI_BEGIN_REQUEST x
627 FCGI_ABORT_REQUEST x
628 FCGI_END_REQUEST
629 FCGI_PARAMS x x
630 FCGI_STDIN x x
631 FCGI_DATA x x
632 FCGI_STDOUT x
633 FCGI_STDERR x
634
635</code></pre></div></div>
636
637<h3 id="b-typical-protocol-message-flow"><a name="SB">B. Typical Protocol Message Flow</a></h3>
638
639<p>Additional notational conventions for the examples:</p>
640
641<ul>
642 <li>The <tt>contentData</tt> of stream records (<tt>FCGI_PARAMS</tt>, <tt>FCGI_STDIN</tt>, <tt>FCGI_STDOUT</tt>, and <tt>FCGI_STDERR</tt>) is represented as a character string. A string ending in <tt>” … “</tt> is too long to display, so only a prefix is shown.</li>
643 <li>Messages sent to the Web server are indented with respect to messages received from the Web server.</li>
644 <li>Messages are shown in the time sequence experienced by the application.</li>
645</ul>
646
647<p>1. A simple request with no data on <tt>stdin</tt>, and a successful response:</p>
648
649<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{FCGI_BEGIN_REQUEST, 1, {FCGI_RESPONDER, 0}}
650{FCGI_PARAMS, 1, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
651{FCGI_PARAMS, 1, ""}
652{FCGI_STDIN, 1, ""}
653
654 {FCGI_STDOUT, 1, "Content-type: text/html\r\n\r\n<html>\n<head> ... "}
655 {FCGI_STDOUT, 1, ""}
656 {FCGI_END_REQUEST, 1, {0, FCGI_REQUEST_COMPLETE}}
657</code></pre></div></div>
658
659<p>2. Similar to example 1, but this time with data on <tt>stdin</tt>. The Web server chooses to send the parameters using more <tt>FCGI_PARAMS</tt> records than before:</p>
660
661<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{FCGI_BEGIN_REQUEST, 1, {FCGI_RESPONDER, 0}}
662{FCGI_PARAMS, 1, "\013\002SERVER_PORT80\013\016SER"}
663{FCGI_PARAMS, 1, "VER_ADDR199.170.183.42 ... "}
664{FCGI_PARAMS, 1, ""}
665{FCGI_STDIN, 1, "quantity=100&item=3047936"}
666{FCGI_STDIN, 1, ""}
667
668 {FCGI_STDOUT, 1, "Content-type: text/html\r\n\r\n<html>\n<head> ... "}
669 {FCGI_STDOUT, 1, ""}
670 {FCGI_END_REQUEST, 1, {0, FCGI_REQUEST_COMPLETE}}
671</code></pre></div></div>
672
673<p>3. Similar to example 1, but this time the application detects an error. The application logs a message to <tt>stderr</tt>, returns a page to the client, and returns non-zero exit status to the Web server. The application chooses to send the page using more <tt>FCGI_STDOUT</tt> records:</p>
674
675<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{FCGI_BEGIN_REQUEST, 1, {FCGI_RESPONDER, 0}}
676{FCGI_PARAMS, 1, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
677{FCGI_PARAMS, 1, ""}
678{FCGI_STDIN, 1, ""}
679
680 {FCGI_STDOUT, 1, "Content-type: text/html\r\n\r\n<ht"}
681 {FCGI_STDERR, 1, "config error: missing SI_UID\n"}
682 {FCGI_STDOUT, 1, "ml>\n<head> ... "}
683 {FCGI_STDOUT, 1, ""}
684 {FCGI_STDERR, 1, ""}
685 {FCGI_END_REQUEST, 1, {938, FCGI_REQUEST_COMPLETE}}
686</code></pre></div></div>
687
688<p>4. Two instances of example 1, multiplexed onto a single connection. The first request is more difficult than the second, so the application finishes the requests out of order:</p>
689
690<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{FCGI_BEGIN_REQUEST, 1, {FCGI_RESPONDER, FCGI_KEEP_CONN}}
691{FCGI_PARAMS, 1, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
692{FCGI_PARAMS, 1, ""}
693{FCGI_BEGIN_REQUEST, 2, {FCGI_RESPONDER, FCGI_KEEP_CONN}}
694{FCGI_PARAMS, 2, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
695{FCGI_STDIN, 1, ""}
696
697 {FCGI_STDOUT, 1, "Content-type: text/html\r\n\r\n"}
698
699{FCGI_PARAMS, 2, ""}
700{FCGI_STDIN, 2, ""}
701
702 {FCGI_STDOUT, 2, "Content-type: text/html\r\n\r\n<html>\n<head> ... "}
703 {FCGI_STDOUT, 2, ""}
704 {FCGI_END_REQUEST, 2, {0, FCGI_REQUEST_COMPLETE}}
705 {FCGI_STDOUT, 1, "<html>\n<head> ... "}
706 {FCGI_STDOUT, 1, ""}
707 {FCGI_END_REQUEST, 1, {0, FCGI_REQUEST_COMPLETE}}
708</code></pre></div></div>
709
710<hr />
711
712<p><strong>© 1995, 1996 Open Market, Inc. / <a href="https://www.linkedin.com/in/mark-brown-32a01b11/">Mark R. Brown</a></strong></p>
713
714
715 <footer class="site-footer">
716
717 <span class="site-footer-owner"><a href="https://github.com/FastCGI-Archives">FastCGI Github Archives</a> is maintained by <a href="https://github.com/mcarbonneaux">mcarbonneaux</a>.</span>
718
719 </footer>
720 </section>
721
722
723 <!-- Google tag (gtag.js) -->
724 <script async src="https://www.googletagmanager.com/gtag/js?id=G-Y204H06GVK"></script>
725 <script>
726 window.dataLayer = window.dataLayer || [];
727 function gtag(){dataLayer.push(arguments);}
728 gtag('js', new Date());
729
730 gtag('config', 'G-Y204H06GVK');
731 </script>
732
733
734 </body>
735</html>