CGI and Parameter Input
In the web server context CGI mean Common Gateway Interface. A fancy name for an executable of some sort. Executable in this context usually means some form of script that will do something and return some sort of response to the requesting client.
The first question of course is how does the web server recognize a request for a script. Typically the path in the requesting url is something like url/cgi-bin/scriptname. The server directs requests with cgi-bin in the path to scripts within a specific location in the server file structure. Normally a regular user is prevented from uploading anything to this location so that here is no possibility of a user inserting their own script into the server for nefarious purposes.
For our roll you own web server a lot depends upon the environment you are using and the file structure you are using. For example you could recognize cgi-bin in the path and use the resource name as then name of some program or script (depending upon your platform). Since I am using REXX I simply added code to the main server loop that recognized a resource type of EXEC and used the resource name as the name of the REXX exec to call.
Obviously if you want to invoke scripts of some sort then you are likely to want to be able to pass data into those scripts so that they can act upon it. The HTTP protocol allows for two ways to pass data to the server. The first is by encoding the data as keyword/value pairs within the URL itself. A question mark (?) is used to separate the url resource (typically the script name or an alias for some service on the server that is to be invoked) from the parameters. Each keyword/data pair of parameters is then separated from the others with an ampersand (&). An example of such a url might be:
The resource is signin.exec (some sort of rexx exec to validate a users signin maybe!). It is being passed two parameters, fname and lname. You can see the question mark separating the resource part of the url from the following parameters and the ampersand separating each keyword/value pair.
This type of parameter passing is called GET. You may see a parameters such as method=”get” of forms for example. This means that the data from the form will be passed to the server within the url as shown. Be aware that browsers may (or may not) cache the results of ‘get’ requests like this so that whilst the initial request may result in a request going to the server, subsequent requests (using the same parameters and values) may be satisfied from the browser’s cache instead of a request being made to the server.
The other method of parameter passing is called ‘POST’. With this form of data transmittal, the data follows the two crlf characters that mark the end of the HTTP header. The url part of the request would still specify the name of the script or service to be invoked. The advantage of using the post method is that it allows for much larger amounts of data to be sent to the server and the result is never cached by the browser.
Which ever method is used to transmit data to your server as part of a request, you need to be able to extract if from the HTTP request and save it so that it can be passed to the processing script (or whatever) specified by the resource location.