|GateCGI content generator component executes
external applications and scripts according to rules compatible with the CGI/1.1 standard.
As mentioned CCGA defines that query string is always in the parameter=value&...
form thus CGI processors not capable of parsing this query string format will not work.
Another differences are caused by the ALP local nature and URL parsing mechanism - i.e.
host names, ports and so on. Most headers have no meaning in the ALP and are ignored (of
course Content-Type is required). Below most important rules about executing CGI with ALP
- Environment, URL, name substitutions. According to the ALP URL parsing scheme environment variables containing host names
and parts of the URL will contain corresponding ALP URL parts:
- HTTP_HOST and SERVER_NAME. Contain the "host name" part of the URL that means
in the ALP notation ALP site URL - i.e. they will always be something similar to this one:
C:/ALP/site1/ (Assume that you have alp.site file in that path - see ALP URL and alp.site).
- SERVER_PORT. Always contains 80 in order to prevent applications from adding ":XX
" explicit port specifications to the URL when generating it.
- SERVER_SOFTWARE. In ALP case it contains newObjects-ALP/1.0. This string is defined by
the content generator host thus it will not be the same if you GateCGI runs in another
environment (ALP WEB Share is planned for release later this year - it will define another
string). Don't forget that GateCGI is a module that can be loaded by another hosts.
- HTTP_USER_AGENT. As mentioned in other ports of this documentation we encountered
problems with standard API in this direction and we can say that not all versions of IE
are capable of providing such information to non http(s) protocols. Thus it is fixed to Mozilla/4.0
(compatible; MSIE 4.01; Win32). Later versions of the ALP will implement walk
around for this problem.
- PATH_TRANSLATED. Contains physical path corresponding to the ALP site containing the
- SCRIPT_NAME. Contains full virtual path and name of the executed script. For example if
your site begins in C:\alp\site1 directory and your script resides in
C:\alp\site1\cgi\acgi.exe SCRIPT_NAME will contain /cgi/acgi.exe.
- GATEWAY_INTERFACE. GateCGI fills there CGI/1.1
- REQUEST_METHOD. Specified by the host - i.e. in case of ALP by the ALP core. Current
version supports GET and POST methods. If no method is passed GateCGI fills in GET.
- CONTENT_LENGTH. Contains length of the content that CGI application can read from the
input stream in bytes. Not meaningful for the GET method.
- CONTENT_TYPE. Specifies the content type of the data available in the input. In this
version you can expect only application/x-www-form-url-encoded data for the POSTs but this
may change in future and especially if the host is not ALP.
- QUERY_STRING. Contains the parameter=value pairs passed through the URL after
the ? sign. Although that it is passed as a command line parameter to your script it is
recommended to use this environment variable instead - configuration syntax allows
omitting of this parameter.
- Additional environment. By using the ENVIRONMENT section in the GateCGI configuration you can add or/and replace some
environment variables. You may need this option in order to prepare appropriate
environment for the CGI scripts in your application. All other environment variables
available for the application that uses ALP engine (usually Internet Explorer) are passed
- Direct execution and script engine. GateCGI supports two types of CGI
configuration. For example .EXE files are registered to be executed as CGI applications in
the default configuration file and in the examples you can see several registrations of
cmd files and script files for the WSH including the Engine record entry - see GateCGI configuration for details
POST data is available for the CGI applications through the standard input stream. Both
standard output and standard error output streams are mixed and treated by the GateCGI as
CGI output. Please don't rely on the standard error for outputting the content - we will
attach this pipe to a GateCGI extension in future versions thus it will be used as a
control line - of course module will support configuration giving compatibility with
previous versions, but planning applications in a wrong manner can cause a problems if you
want to use the extended features later.