As an additional security measure, this script runs finger explicitly as /usr/bin/finger. In the unlikely event that the web server passes your CGI program an unusual PATH, running just finger may cause the wrong program to execute. Another security measure you can take is to examine the PATH environment variable and make sure it has an acceptable value. It's a good idea to remove the current working directory from PATH unless you are sure that it is not the case where you actually need to execute the program in it.

Another important security consideration relates to user rights. By default, the web server runs the CGI program with the rights of the user who started the server itself. This is usually a pseudo-user such as "nobody" that has limited rights, so the CGI program has few rights either. This is usually a good thing, because if an attacker can gain access to the server through a CGI program, he won't be able to do much damage. The example of a password stealing program shows what can be done, but the actual damage to the system is usually limited.

However, running as a limited user also limits the capabilities of CGI. If a CGI program needs to read or write files, it can only do so where it has such permission. For example, in the second example of storing state, a file is maintained for each user. The CGI program must have read and write permission on the directory containing these files, not to mention the files themselves. This can be done by creating the directory as the same user as the server, with read and write permissions only for that user. However, for a user like "nobody", only root has this ability. If you are not a superuser, you will have to communicate with the system administrator every time you make a change to the CGI.

Another way is to make the directory free to read and write, essentially removing all protection from it. Since these files can only be accessed from the outside world through your program, the danger is not as great as it might seem. However, if a flaw is discovered in the program, the remote user will have full access to all files, including the ability to destroy them. In addition, legitimate users running on the server will also be able to modify these files. If you are going to use this method, then all users of the server must be trustworthy. Also, use the open directory only for files that are needed by the CGI program; in other words, don't put unnecessary files at risk.

If this is your first time getting into CGI programming, there are a number of ways you can continue to explore. Dozens of books have been written on this subject, many of which do not assume any knowledge of programming. "CGI Programming on the World Wide Web" published by O"Reilly and Associates, covers material from simple scripts in different languages ​​to truly amazing tricks and tricks. Public information is also available in abundance on the WWW. A good place to start is CGI Made Really Easy(Really just about CGI) at http://www.jmarshall.com/easy/cgi/ .

CGI and databases

Since the dawn of the Internet era, databases have interacted with the development of the World Wide Web. In practice, many people view the Web as simply one giant database of multimedia information.

Search engines provide an everyday example of the benefits of databases. The search engine doesn't go roaming the entire Internet looking for keywords the moment you ask for them. Instead, site developers use other programs to create a giant index that serves as a database from which the search engine retrieves entries. Databases store information in a form that allows rapid, random access retrieval.

Because they're fluid, databases give the Web even more power: they make it a potential interface for anything. For example, system administration can be done remotely via a web interface instead of requiring an administrator to log in to the desired system. Connecting databases to the Web is at the heart of a new level of interactivity on the Internet.

One of the reasons for connecting databases to the Web regularly makes itself known: much of the world's information is already in databases. Databases that predate the Web are called legacy databases (as opposed to non-Web-connected databases created more recently, which should be called a "bad idea"). Many corporations (and even individuals) are now faced with the challenge of providing access to these legacy databases via the Web. Unless your legacy database is MySQL or mSQL, this topic is beyond the scope of this book.

As stated earlier, only your imagination can limit the possibilities of communication between databases and the Web. Currently, there are thousands of unique and useful databases accessible from the Web. The types of databases that operate outside of these applications vary widely. Some of them use CGI programs as an interface to a database server such as MySQL or mSQL. These types are of greatest interest to us. Others use commercial applications to interface with popular desktop databases such as Microsoft Access and Claris FileMaker Pro. Others simply work with flat text files, which are the simplest databases possible.

Using these three types of databases, you can develop useful websites of any size or complexity. One of our goals over the next few chapters will be to apply the power of MySQL mSQL to the Web using CGI programming.

Introduction.

In this article I want to talk about the CGI interface in general, its implementation for Windows and the use of assembly language in particular when writing CGI programs. The scope of this article does not include a full description of CGI, since there is simply a sea of ​​material on this issue on the Internet and I simply don’t see the point in retelling it all here.

TheoryCGI.

CGI – (Common Gateway Interface) – Common Gateway Interface. As you might guess, this interface serves as a gateway between the server (here I mean the server program) and some external program written for the OS on which this very server is running. Thus, CGI is responsible for exactly how data will be transferred from the server program to the CGI program and back. The interface does not impose any restrictions on what the CGI program should be written in; it can be either a regular executable file or any other file - the main thing is that the server can run it (in the Windows environment, for example, it can be a file with the extension tied to any program).

From the moment you called (for example, clicked a form button to which a CGI program call is attached) the CGI program until you receive the result in your browser window, the following happens:

A web client (such as a browser) creates a connection to the server specified in the URL;

The web client sends a request to the server, this request is usually made using two methods GET or POST;

Data from the client request (for example, form field values) is passed by the server, using a CGI interface, to the CGI program specified in the URL;

The CGI program processes the client data received from the server and, based on this processing, generates a response to the client, which it transmits via the same CGI interface to the server, and it, in turn, transmits it directly to the client;

The server closes the connection with the client.

The standard CGI specification assumes that the server can communicate with the program in the following ways:

Environment variables – they can be set by the server when the program starts;

Standard input stream (STDIN) - with its help, the server can transfer data to the program;

Standard output stream (STDOUT) – the program can write its output into it, which is transmitted to the server;

Command line – in it the server can pass some parameters to the program.

Standard input/output streams are very convenient and widely used on UNIX systems, which cannot be said about Windows, so there is a CGI specification developed specifically for Windows systems, called “Windows CGI”. But, of course, standard input/output streams can also be used in windows CGI programming. Here I will not touch on the “Windows CGI” standard, and there are at least two reasons for this - the first, and most important, is that at the moment not all http servers for Windows support this specification (in particular, my favorite Apache 1.3.19) . You can see the second reason by typing “Windows CGI” in any search engine. I will note only general details regarding this interface - all data from the server to the client is transferred through a file that is usual for Windows *.ini, the name of which is passed to the program on the command line. In this case, all the data in the file is already carefully divided into sections by the server and all you have to do is use the “GetPrivateProfile*” functions to extract them from there. The response is sent to the server again through a file whose name is indicated in the corresponding entry in the ini file.

What data can be transferred by the client to the CGI program? - almost any. In general, the program is passed the values ​​of the form fields that the client fills out, but it can also be some kind of binary data, for example, a file with a picture or music. Data can be transferred to the server by two different methods - the GET method and the POST method. When we create a form to be filled out on our page, we explicitly indicate which of the given methods we want to send the data entered by the user, this is done in the main tag of the form something like this:

get action="/cgi-bin/name_script">

When sending data using the GET method, the browser reads the data from the form and places it after the script URL, followed by a question mark; if there are several significant fields in the form, then they are all transmitted through the “&” sign, the field name and its value are written in the URL through the “=” sign " For example, a request generated by a browser from a form when you click on a button to which the script “/cgi-bin/test.exe” is attached, taking into account that the first field of the form is called “your_name”, the second – “your_age”, may look like this:

GET /cgi-bin/test.exe?your_name=Pupkin&your_age=90 HTTP/1.0

Using the GET method has several weaknesses - the first and most important is because The data is transmitted in the URL, then it has a limit on the amount of this transmitted data. The second weakness again follows from the URL - this is confidentiality, with such a transfer the data remains absolutely open. So, it’s good if we have 2-3 small fields in the form... the question arises, what to do if there is more data? The answer is to use the POST method!

When using the POST method, the data is transmitted to the server as a block of data, and not in a URL, which somewhat frees our hands to increase the amount of information transmitted; for the above example of the POST form, the block sent to the server will be something like this:

POST /cgi-bin/test.exe HTTP/1.0

Accept: text/plain

Accept: text/html

Accept: */*

Content-type: application/x-www-form-urlencoded

Content-length: 36

your_name=Pupkin&your_age=90

As mentioned above, after receiving the data, the server must convert it and pass it to the CGI program. In the standard CGI specification, client input for a GET request is placed by the server in the program's environment variable "QUERY_STRING". When a POST request is made, the data is placed on the application's standard input stream, where it can be read by it. In addition, with such a request, the server sets two more environment variables - CONTENT_LENGTH and CONTENT_TYPE, by which one can judge the length of the request in bytes and its content.

In addition to the data itself, the server also sets other environment variables of the called program; here are some of them:

REQUEST_METHOD

Describes exactly how the data was obtained

Example:REQUEST_METHOD=GET

QUERY_STRING

Query string if GET method was used

Example:QUERY_STRING= your_name=Pupkin&your_age=90&hobby=asm

CONTENT_LENGTH

Length in bytes of the request body

Example:CONTENT_LENGTH=31

CONTENT_TYPE

Request body type

GATEWAY_INTERFACE

CGI protocol version

Example:GATEWAY_ INTERFACE= CGI/1.1

REMOTE_ADDR

IP address of the remote host, that is, the client who clicked the button in the form

Example:REMOTE_ADDR=10.21.23.10

REMOTE_HOST

The name of the remote host, this can be its domain name or, for example, the name of a computer in a Windows environment; if these cannot be obtained, then the field contains its IP

Example:REMOTE_HOST=wasm.ru

SCRIPT_NAME

The name of the script used in the request.

Example:SCRIPT_NAME=/cgi-bin/gols.pl

SCRIPT_FILENAME

The name of the script file on the server.

Example:SCRIPT_FILENAME=c:/page/cgi-bin/gols.pl

SERVER _ SOFTWARE

Server software

Example: Apache/1.3.19 (WIN32)

In general, this is all in brief, for more detailed information about the Common Gateway Interface, see the specialized documentation, I made this description in order to remind you, and if you didn’t know, then bring you up to date. Let's try to do something in practice.

Practical part.

For practice, we will need at least 3 things - some kind of http server for Windows, I tried all the examples on Apache 1.3.19 for Windows, the server is free, you can download it from http://httpd.apache.org/download.cgi . Yes, and we will need a server, not just any server, but one configured to run CGI scripts! See the documentation for how to do this for the server you are using. The second thing we need is, of course, an assembler; it is also necessary that the compiler supports the creation of WIN32 console applications, I use Tasm, but Fasm and Masm and many other *asms are perfect. And finally, the most important thing is that this desire is required.

So, I assume that the server was successfully installed and configured by you, so that in the root directory of the server documents there is an index.html file, which is perfectly displayed in the browser when you type the address http://127.0.0.1. I will also take into account that somewhere in the jungle of server folders there is a “cgi-bin” folder in which scripts are allowed to run.

Let's check the server settings, and at the same time write a small script. Our script will be a regular *.bat file. I foresee questions - how? really? Yes, this is an ordinary batch file, as mentioned above, the CGI specification does not distinguish between file types, the main thing is that the server can run it, and it, in turn, has access to stdin/stdout and environment variables, a bat file, even not fully, but for an example it will suit us quite well. Let's create a file with approximately the following content:

@echo off rem Request header echo Content-type: text/html echo. rem Request body echo " Hello!
echo "The GET request sent the following data: %QUERY_STRING%

Let's call the file test.bat and place it in the directory for running scripts, most likely it will be the “cgi-bin” directory. The next thing we need to do is call this script in some way, in principle, this can be done directly by typing something like the following “http://127.0.0.1/cgi-bin/test.bat” into the browser address window, but let’s Let's call it from our main page, and at the same time check the operation of the GET method. Let's create a file index.html in the server root with the following content:

Now, when you enter the server (http://127.0.0.1 in the browser address bar), a form should appear, type something in it and click the “send” button, if everything was done correctly, you will see the response from our bat- in the browser window script. Now let's see what we got up to there.

As you might guess, the “echo” command outputs to stdout; first of all, we pass the header of our response to the server – “echo Content-type: text/html”. This is a standard CGI specification header, indicating that we want to transfer text or an html document; there are other headers. A very important point is the title. must separated from the response body by an empty line, which is what we do with the following “echo.” command. Next, the body of the response itself is transmitted - this is a regular html document. In the body of the document, for clarity, I display one of the environment variables passed to us by the server - “QUERY_STRING”, as already mentioned with the GET method (and this is exactly our case), everything is transmitted in this variable user-entered data, which we can observe in the script response. You may have noticed “the quotation marks are out of place” in the last 2 lines of the file, immediately after “echo”, they are there because of the specificity of bat files, as you can see the html tags are surrounded by the characters “<» и «>", at the same time, these symbols serve as input/output redirection in bat files, and therefore we cannot freely use them here.

I recommend playing around a little with such bat scripts, it can be very useful, try looking at other environment variables. I’ll say a little, deviating from the topic, on UNIX systems, command interpreter languages ​​are very highly developed and the line between programming in a command interpreter language and programming in a “real” programming language is very, very blurry in some cases, so simple scripts are often written on UNIX systems specifically in command interpreter languages, but the Windows interpreter cmd.exe or, earlier, command.com are clearly weak for these purposes.

Now let's move on to the most important task of this article, to actually writing a CGI program in assembler. In principle, if we take into account all of the above about CGI, we can draw a conclusion about what the CGI interface requires from our program:

2. The program must be able to write to the standard output stream (stdout) in order to transmit the result of its work to the server;

3. From the first two points it follows that in order for the server to send something to our program in stdin, and for it to respond to it in stdout, the CGI program must be a console application;

This is quite enough to create a full-fledged CGI application.

Let's start with the last point. To gain access to the environment variables of a Windows application, the API function “GetEnvironmentStrings” is used, the function has no arguments and returns a pointer to an array of environment variables (NAME=VALUE) separated by zero, the array is closed with a double zero, when the program is launched by the server in the program environment in addition to standard variables, specific CGI variables described above are added; when you run the program from the command line, you will not see them, naturally.

In order to write something to stdout or read from stdin, we first need to get the handles of these streams, this is done using the API function “GetStdHandle”, one of the following values ​​is passed as a function parameter:

STD_INPUT_HANDLE - for stdin (standard input);

STD_OUTPUT_HANDLE - for stdout (standard output);

STD_ERROR_HANDLE - for stderr.

The function will return the handle we need for read/write operations. The next thing we need to do is write/read these streams. This is done by normal file read/write operations, i.e. ReadFile and WriteFile. There is one subtlety here, you might think that WriteConsole/ReadConsole can be used for these purposes, but this is indeed true for consoles and it will work great, the results, just like with WriteFile, will be output to the console, but this will continue until we run our program as a script on the server. This happens because when our program is launched by the server, the handles returned by the “GetStdHandle” function will no longer be console handles as such, they will be pipe handles, which is necessary for connecting two applications.

Here is a small example of what a CGI program should look like in assembly language; I think it won’t be too difficult to figure it out:>

386 .model flat,stdcall includelib import32.lib .const PAGE_READWRITE = 4h MEM_COMMIT = 1000h MEM_RESERVE = 2000h STD_INPUT_HANDLE = -10 STD_OUTPUT_HANDLE = -11 .data hStdout dd ? hStdin dd ? hMem dd ? header: db "Content-Type: text/html",13,10,13,10,0 start_html: db " The CGI program environment looks like this:
",13,10,0 for_stdin: db " The STDIN of the program contains:
",13,10,0 end_html: db "",13,10,0 nwritten dd ? toscr db 10 dup (32) db " - File type",0 .code _start: xor ebx,ebx call GetStdHandle,STD_OUTPUT_HANDLE mov hStdout,eax call GetStdHandle,STD_INPUT_HANDLE mov hStdin,eax call write_stdout, offset header call write_stdout, offset start_html call VirtualAlloc,ebx,1000,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE mov hMem,eax mov edi,eax call GetEnvironmentStringsA mov esi,eax next_symbol: mov al, or al,al jz end_string mov ,al next_string : cmpsb jmp short next_symbol end_string: mov ,">rb<" add edi,3 cmp byte ptr ,0 jnz next_string inc edi stosb call write_stdout, hMem call write_stdout, offset for_stdin call GetFileSize,,ebx mov edi,hMem call ReadFile,,edi, eax,offset nwritten, ebx add edi, mov byte ptr ,0 call write_stdout, hMem call write_stdout, offset end_html call VirtualFree,hMem call ExitProcess,-1 write_stdout proc bufOffs:dword call lstrlen,bufOffs call WriteFile,,bufOffs,eax,offset nwritten,0 ret write_stdout endp extrn GetEnvironmentStringsA:near extrn GetStdHandle:near extrn ReadFile:near extrn WriteFile:near extrn GetFileSize:near extrn VirtualAlloc:near extrn VirtualFree:near extrn ExitProcess:near extrn lstrlen:near ends end _start

The executable file is built with the commands:

tasm32.exe /ml test.asm

tlink32.exe /Tpe /ap /o test.obj

Don't forget that the program must be a console program.

Archive with the program.

You can call this program using the html form described above, you just need to change the name test.bat in the form to test.exe and copy it to /cgi-bin/ accordingly, you can set it to POST in the request method, the program processes it.

I also want to note that you can call the program in another way, you can create a file in the cgi-bin directory, for example test.cgi, with one single line “#!c:/_path_/test.exe” and call it in requests, and the server in in turn, will read its first line and launch the exe file; for this, it is necessary that the *.cgi extension be specified in the http server settings as an extension for scripts. With this approach, the server will launch our program with the command line “test.exe path_to_test.exe” this has several advantages - the first is that the person running our script will not even guess what the script is written in, the second is the way it is transmitted to us the name of the file with our line, we can, for example, add any settings for our script to this file, which simplifies debugging, by the way, this is how all interpreters work - you may have noticed that in all perl/php/etc programs there is a similar line - indicating to the command interpreter itself. So, when the server starts a cgi program, if the program extension is registered as a script in the settings, it reads the first line of the file, and if it turns out to be in the format described above, then it launches the program specified in the line with the name of this file followed by a space, let’s say that in The pearl interpreter is indicated in the line; having received such a gift, it begins its execution, because The comment in Perl is the “#” symbol, then it skips the first line and the script continues to be executed, in general it’s a convenient thing.

That’s basically all I wanted to write about, I don’t know how useful all of this will be to you, but I will say that I have an intranet server running using assembler scripts. I confess, there was no great reason to do this, but nevertheless, I did it at first simply for aesthetic reasons and some reluctance to learn pearl/php or something else. BUT I am in no way dissuading you from learning Pearl, but on the contrary, I will say that it is necessary to do this, and even very necessary, I realized this later, but I still think that on heavily loaded servers, where the speed of execution, loading and the amount of memory occupied by the application plays a role cgi scripts written in assembler will take their rightful place.

• Tutorial

Good afternoon.
In this article I would like to talk about the FastCGI protocol and how to work with it. Despite the fact that the protocol itself and its implementation appeared back in 1996, there are simply no detailed manuals for this protocol - the developers never wrote help for their own library. But two years ago, when I just started using this protocol, I often heard phrases like “I don’t quite understand how to use this library.” It is this shortcoming that I want to correct - to write a detailed guide to using this protocol in a multi-threaded program and recommendations for choosing various parameters that anyone could use.

The good news is that the method of encoding data in FastCGI and in CGI is the same, only the method of transmitting it changes: if a CGI program uses the standard input-output interface, then a FastCGI program uses sockets. In other words, you just need to understand a few functions of the library for working with FastCGI, and then just use the experience of writing CGI programs, of which, fortunately, there are a lot of examples.

So, in this article we will look at:
- What is FastCGI and how does it differ from the CGI protocol
- Why do I need FastCGI when there are already many languages ​​for web development
- What implementations of the FastCGI protocol exist?
- What are sockets
- Description of FastCGI library functions
- A simple example of a multi-threaded FastCGI program
- Simple Nginx configuration example
Unfortunately, it is very difficult to write an article that is equally understandable for beginners and interesting for experienced old-timers, so I will try to cover all the points in as much detail as possible, and you can simply skip sections that are not interesting to you.

What is FastCGI?

Why do I need FastCGI when I already have PHP, Ruby, Python, Perl, etc.?

Which web server with FastCGI support is better to choose?

What implementations of the FastCGI protocol are there?

What are sockets?

How to use the Libfcgi library?

Next we need to open a listening socket:
int FCGX_OpenSocket(const char *path, int backlog);
The path variable contains the socket connection string. Both Unix domain sockets and TCP sockets are supported; the library will do all the necessary work on preparing parameters and calling a function.
Example connection strings for Unix domain sockets:
"/tmp/fastcgi/mysocket" "/tmp/fcgi_example.bare.sock"
I think everything is clear here: you just need to pass a unique path as a string, and all processes interacting with the socket must have access to it. I repeat once again: this method only works within one computer, but is somewhat faster than TCP sockets.
Example connection strings for TCP sockets:
":5000" ":9000"
In this case, a TCP socket is opened on the specified port (in this case, 5000 or 9000, respectively), and requests will be accepted from any IP address. Attention! This method is potentially unsafe - if your server is connected to the Internet, then your FastCGI program will accept requests from any other computer. This means that any attacker will be able to send a “death packet” to your FastCGI program. Of course, there is nothing good about this - in the best case, your program can simply “crash” and result in a denial of service (DoS attack, if you want), in the worst case, remote code execution (if you’re really unlucky), so always limit access to such ports using a firewall (firewall), and access should be granted only to those IP addresses that are actually used during the normal operation of the FastCGI program (the principle of “everything that is not explicitly allowed is prohibited”).
The following is an example of connection strings:
"*:5000" "*:9000"
The method is completely similar to the previous one: a TCP socket is opened to accept connections from any IP address, so in this case it is also necessary to carefully configure the firewall. The only advantage of such a connection line is purely administrative - any programmer or system administrator reading the configuration files will understand that your program accepts connections from any IP address, so, other things being equal, it is better to prefer this option to the previous one.
A safer option is to explicitly specify the IP address in the connection string:
"5.5.5.5:5000" "127.0.0.1:9000"
In this case, requests will be accepted only from the specified IP address (in this case - 5.5.5.5 or 127.0.0.1, respectively), for all other IP addresses this port (in this case - 5000 or 9000, respectively) will be closed. This increases overall system security, so whenever possible, always use this connection string format for TCP sockets - what if the system administrator “simply forgets” to configure the firewall? Please pay attention to the second example - the address of the same machine (localhost) is indicated there. This allows you to create a TCP socket on the same machine if for some reason you cannot use Unix domain sockets (for example, because the web server chroot and the FastCGI program chroot are in different folders and do not have common file paths ). Unfortunately, you cannot specify two or more different IP addresses, so if you really need to accept requests from multiple web servers located on different computers, you will either have to open the port completely (see the previous method) and rely on the settings of your firewall, or use multiple sockets on different ports. Also, the libfcgi library does not support IPv6 addresses - back in 1996, this standard was just born, so you will have to limit your appetites to ordinary IPv4 addresses. True, if you really need IPv6 support, it is relatively easy to add it by patching the FCGX_OpenSocket function - the library license allows this.
Attention! Using the function of specifying an IP address when creating a socket is not sufficient protection - IP spoofing attacks (substituting the IP address of the packet sender) are possible, so setting up a firewall is still required. Typically, as protection against IP spoofing, the firewall checks the correspondence between the IP address of the packet and the MAC address of the network card for all hosts on our local network (more precisely, for the broadcast domain with our host), and discards all packets coming from the Internet whose return address is in the zone of private IP addresses or local host (masks 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, 127.0.0.0/8 and::1/128). However, it is still better to use this library feature - in the case of an incorrectly configured firewall, sending a “death packet” from a forged IP address is much more difficult than from any other one, since the TCP protocol has built-in protection against IP spoofing.
The last kind of connection string is to use the host's domain name:
"example.com:5000" "localhost:9000"
In this case, the IP address will be obtained automatically based on the domain name of the host you specified. The restrictions are still the same - the host must have one IPv4 address, otherwise an error will occur. However, given that the socket is created once at the very beginning of working with FastCGI, this method is unlikely to be very useful - dynamically changing the IP address will still not work (more precisely, after each change of the IP address you will have to restart your FastCGI program). On the other hand, perhaps this will be useful for a relatively large network - remembering a domain name is still easier than an IP address.

The second parameter of the backlog function specifies the length of the socket request queue. The special value 0 (zero) indicates the default queue length for this operating system.
Every time a request comes from the web server, a new connection is placed in this queue, waiting to be processed by our FastCGI program. If the queue is completely full, all subsequent connection requests will fail - the web server will receive a Connection refused response. In principle, there is nothing wrong with this - the Nginx web server has its own queue of requests, and if there are no free resources, then new requests will wait their turn for processing already in the web server queue (at least until timeout will expire). In addition, if you have several servers running FastCGI, Nginx can pass such a request to a less loaded server.
So, let's try to figure out what the optimal queue length will be. In general, it is better to configure this parameter individually based on load testing data, but we will try to estimate the most suitable range for this value. The first thing you need to know is that the maximum queue length is limited (determined by the operating system kernel settings, usually no more than 1024 connections). Secondly, the queue consumes resources, cheap ones, but still resources, so you shouldn’t make it unreasonably long. Further, let's say our FastCGI program has 8 worker threads (quite realistic for modern 4-8-core processors), and each thread needs its own connection - tasks are processed in parallel. This means, ideally, we should already have 8 requests from the web server in order to immediately, without unnecessary delays, provide work to all threads. In other words, the minimum request queue size is the number of FastCGI program worker threads. You can try to increase this value by 50%-100% to provide some headroom for the load, since the time for data transfer over the network is finite.
Now let's determine the upper limit of this value. Here we need to know how many requests we can actually process and limit the request queue to this value. Imagine that you have made this queue too large - so much so that your customers simply get tired of waiting their turn and they simply leave your site without waiting for a response. Obviously, there is nothing good about this - the web server had to send a request to open a connection, which in itself is expensive, and then close this connection only because the FastCGI program did not have enough time to process this request. In a word, we are only wasting processor time, but we just don’t have enough of it! But this is not the worst thing - it’s worse when the client refuses to receive information from your site already after the request has begun to be processed. It turns out that we will have to completely process an essentially useless request, which, you see, will only worsen the situation. Theoretically, a situation may arise when most of the clients will not wait for a response when your processor is 100% loaded. Not good.
So, let's say we can process one request in 300 milliseconds (that is, 0.3 seconds). Next, we know that on average, 50% of visitors leave a resource if a web page takes more than 30 seconds to load. Obviously, 50% of dissatisfied people is too much, so we will limit the maximum page loading time to 5 seconds. This means a completely finished web page - after applying cascading style sheets and executing JavaScript - this stage on an average site can take 70% of the total loading time of a web page. So, no more than 5 minutes are left for loading data over the network *0.3 = 1.5 seconds. Next, you should remember that the html code, style sheets, scripts and graphics are transferred in different files, and first the html code, and then everything else. However, after receiving the html code the browser begins to request the remaining resources in parallel, so we can estimate the loading time of the html code as 50% of the total time for receiving data.So, we have no more than 1.5 * 0.5 = 0.75 seconds left to process one request. If on average one thread processes a request in 0.3 seconds, then there should be 0.75/0.3 = 2.5 requests per thread in the queue. Since we have 8 worker threads, the resulting queue size should be 2.5 *8 = 20 requests I would like to note that the above calculations are conditional - if you have a specific site, the values ​​used in the calculation can be determined much more accurately, but it still provides a starting point for more optimal performance tuning.

So, we have received a socket descriptor, after which we need to allocate memory for the request structure. The description of this structure is as follows:
typedef struct FCGX_Request ( int requestId; int role; FCGX_Stream *in; FCGX_Stream *out; FCGX_Stream *err; char **envp; struct Params *paramsPtr; int ipcFd; int isBeginProcessed; int keepConnection; int appStatus; int nWriters; int flags; int listen_sock; int detached; ) FCGX_Request;
Attention! After receiving a new request, all previous data will be lost, so if you need to store data for a long time, use deep copying (copy the data itself, not pointers to the data).
You should know the following about this structure:
- the variables in, out and err play the role of input, output and error streams, respectively. The input stream contains the POST request data, the response of the FastCGI program (for example, http headers and html code of the web page) must be sent to the output stream, and the error stream will simply add an entry to the web server error log. In this case, you don’t have to use the error stream at all - if you really need to log errors, then, perhaps, it is better to use a separate file for this - transferring data over the network and its subsequent processing by the web server consumes additional resources.
- the envp variable contains the values ​​of environment variables set by the web server and http headers, for example: SERVER_PROTOCOL, REQUEST_METHOD, REQUEST_URI, QUERY_STRING, CONTENT_LENGTH, HTTP_USER_AGENT, HTTP_COOKIE, HTTP_REFERER and so on. These headers are defined by the CGI and HTTP protocol standards, respectively; examples of their use can be found in any CGI program. The data itself is stored in an array of strings, with the last element of the array containing a null pointer (NULL) to indicate the end of the array. Each line (each element of the string array) contains one variable value in the format VARIABLE_NAME=VALUE, for example: CONTENT_LENGTH=0 (in this case, it means that this request does not have POST data, since its length is zero). If the envp string array does not contain the header you need, it means it was not transmitted. If you want to get all the variable values ​​passed to the FastCGI program, simply read all the lines of the envp array in a loop until you encounter a pointer to NULL.
Actually, we’re done with the description of this structure - you won’t need all the other variables.

The memory has been allocated, now you need to initialize the request structure:
int FCGX_InitRequest(FCGX_Request *request, int sock, int flags);
The function parameters are as follows:
request - pointer to the data structure to be initialized
sock is the socket descriptor that we received after calling the FCGX_OpenSocket function. I would like to note that instead of a ready-made descriptor, you can pass 0 (zero) and receive a socket with default settings, but for us this method is not at all interesting - the socket will be opened on a random free port, which means we will not be able to configure our web correctly -server - we do not know in advance where exactly the data needs to be sent.
flags - flags. Actually, only one flag can be passed to this function - FCGI_FAIL_ACCEPT_ON_INTR - do not call FCGX_Accept_r when breaking.

After this you need to receive a new request:
int FCGX_Accept_r(FCGX_Request *request);
You need to pass into it the request structure already initialized at the previous stage. Attention! In a multi-threaded program, you must use synchronization when calling this function.
Actually, this function does all the work with sockets: first, it sends a response to the web server to the previous request (if there was one), closes the previous data channel and releases all resources associated with it (including request structure variables), then it receives a new request, opens a new data channel and prepares new data in the request structure for subsequent processing. If there is an error receiving a new request, the function returns an error code less than zero.

Next, you will probably need to get environment variables; for this you can either process the request->envp array yourself, or use the function
char *FCGX_GetParam(const char *name, FCGX_ParamArray envp);
where name is a string containing the name of the environment variable or http header whose value you want to get,
envp - an array of environment variables that are contained in the request->envp variable
The function returns the value of the environment variable we need as a string. Let the attentive reader not be alarmed by the type mismatch between char ** and FCGX_ParamArray - these types are declared synonyms (typedef char **FCGX_ParamArray).
In addition, you will probably need to send a response to the web server. To do this, you need to use the request->out output stream and the function
int FCGX_PutStr(const char *str, int n, FCGX_Stream *stream);
where str is a buffer containing the data to be output, without the terminating null (that is, the buffer can contain binary data),
n - buffer length in bytes,
stream - the stream into which we want to output data (request->out or request->err).

If you use standard null-terminated C strings, it will be more convenient to use the function
int FCGX_PutS(const char *str, FCGX_Stream *stream);
which will simply determine the length of the string using strlen(str) and call the previous function. Therefore, if you know the length of the string in advance (for example, you use C++ std::strings), it is better to use the previous function for efficiency reasons.
I would like to note that these functions work perfectly with UTF-8 strings, so there should be no problems with multilingual web applications.
You can also call these functions several times while processing the same request, in some cases this can improve performance. For example, you need to send a large file. Instead of downloading this entire file from your hard drive and then sending it in one piece, you can start sending data right away. As a result, the client, instead of a white browser screen, will begin to receive the data he is interested in, which, purely psychologically, will force him to wait a little longer. In other words, you kind of gain a little time for the page to load. I would also like to note that most resources (cascading style sheets, JavaScript, etc.) are indicated at the beginning of the web page, that is, the browser will be able to analyze part of the html code and start loading these resources earlier - another reason to display data in parts.

The next thing you may need to do is process the POST request. In order to get its value, you need to read data from the request->in stream using the function
int FCGX_GetStr(char * str, int n, FCGX_Stream *stream);
where str is a pointer to the buffer,
n - buffer size in bytes,
stream - the stream from which we are reading data.
The size of the transmitted data in a POST request (in bytes) can be determined using the environment variable CONTENT_LENGTH, the value of which, as we remember, can be obtained using the FCGX_GetParam function. Attention! Creating a str buffer based on the value of the CONTENT_LENGTH variable without any restrictions is a very bad idea: any attacker can send any POST request, no matter how large, and your server may simply run out of free RAM (this will result in a DoS attack, if you like). Instead, it is better to limit the buffer size to some reasonable value (from a few kilobytes to several megabytes) and call the FCGX_GetStr function several times.

The last important function flashes the output and error streams (sends to the client the still unsent data that we managed to place in the output and error streams) and closes the connection:
void FCGX_Finish_r(FCGX_Request *request);
I would like to especially note that this function is optional: the FCGX_Accept_r function also sends data to the client and closes the current connection before receiving a new request. The question arises: then why is it needed? Imagine that you have already sent the client all the necessary data, and now you need to perform some final operations: write statistics to the database, errors to the log file, etc. Obviously, the connection to the client is no longer needed, but the client (meaning the browser) is still waiting for information from us: what if we send something else? It is obvious that we cannot call FCGX_Accept_r ahead of time - after this we will need to start processing the next request. It is in this case that you will need the FCGX_Finish_r function - it will allow you to close the current connection before receiving a new request. Yes, we will be able to process the same number of requests per unit of time as without using this function, but the client will receive a response earlier - he will no longer have to wait for the end of our final operations, and it is precisely because of the higher request processing speed that we use FastCGI.
This, in fact, ends the description of the library’s functions and begins the processing of the received data.

A simple example of a multi-threaded FastCGI program

#include #include #include #include "fcgi_config.h" #include "fcgiapp.h" #define THREAD_COUNT 8 #define SOCKET_PATH "127.0.0.1:9000" //stores the open socket handle static int socketId; static void *doit(void *a) ( int rc, i; FCGX_Request request; char *server_name; if(FCGX_InitRequest(&request, socketId, 0) != 0) ( //error when initializing the request structure printf("Can not init request\n"); return NULL; ) printf("Request is initiated\n"); for(;;) ( static pthread_mutex_t accept_mutex = PTHREAD_MUTEX_INITIALIZER; //try to receive a new request printf("Try to accept new request\n" ); pthread_mutex_lock(&accept_mutex); rc = FCGX_Accept_r(&request); pthread_mutex_unlock(&accept_mutex); if(rc< 0) { //ошибка при получении запроса printf("Can not accept new request\n"); break; } printf("request is accepted\n"); //получить значение переменной server_name = FCGX_GetParam("SERVER_NAME", request.envp); //вывести все HTTP-заголовки (каждый заголовок с новой строки) FCGX_PutS("Content-type: text/html\r\n", request.out); //между заголовками и телом ответа нужно вывести пустую строку FCGX_PutS("\r\n", request.out); //вывести тело ответа (например - html-код веб-страницы) FCGX_PutS("\r\n", request.out); FCGX_PutS(" \r\n", request.out); FCGX_PutS("\r\n", request.out); FCGX_PutS(" \r\n", request.out); FCGX_PutS("

FastCGI Hello! (multi-threaded C, fcgiapp library)

Request accepted from host ", request.out); FCGX_PutS(server_name ? server_name: "?", request.out); FCGX_PutS("

Simple Nginx configuration example

Server ( server_name localhost; location / ( fastcgi_pass 127.0.0.1:9000; #fastcgi_pass unix:/tmp/fastcgi/mysocket; #fastcgi_pass localhost:9000; include fastcgi_params; ) )

In this case, this config is enough for our FastCGI program to work correctly. The commented lines are an example of working with Unix domain sockets and specifying a domain host name instead of an IP address.
After compiling and running the program and setting up Nginx, I got a proud inscription at the localhost address:
FastCGI Hello! (multi-threaded C, fcgiapp library)

Thanks to everyone who read to the end.