ALP GateCGI Content Generator
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 are listed:
  • 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 CGI.
    • 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 without change.
  • 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.

 

newObjects Copyright 2001-2006 newObjects [ ]