HTTP headers

      The script may return any other headers defined by the HTTP/1.0
      specification [3]. The server must translate the header data from
      the CGI header syntax to the HTTP header syntax if these differ.
      For example, the character sequence for newline (such as Unix's
      ASCII NL) used by CGI scripts may not be the same as that used by
      HTTP (ASCII CR followed by LF). The server must also resolve any
      conflicts between headers returned by the script and headers that
      it would otherwise send itself.

10. Requirements for servers

   Servers must support the standard mechanism (described below) which
   allows the script author to determine what URL to use in documents
   which reference the script. Specifically, what URL to use in order to
   achieve particular settings of the environment variables. This
   mechanism is as follows:

   The value for SCRIPT_NAME is governed by the server configuration and
   the location of the script in the OS file-system. Given this, any
   access to the partial URL

      SCRIPT_NAME extra-path ? query-information

   where extra-path is either NULL or begins with a "/" and satisfies
   any other server requirements, will cause the CGI script to be
   executed with PATH_INFO set to the decoded extra-path, and
   QUERY_STRING set to query-information (not decoded).

   Servers may reject with error 404 any requests that would result in
   an encoded "/" being decoded into PATH_INFO or SCRIPT_NAME, as this




 
INTERNET-DRAFT       Common Gateway Interface - 1.1     15 February 1996


   might represent a loss of information to the script.

   Although the server and the CGI script need not be consistent in
   their handling of URL paths (client URLs and the PATH_INFO data,
   respectively), server authors may wish to impose consistency.  So the
   server implementation should define its behaviour for the following
   cases:

      o define any restrictions on allowed characters, in particular
        whether ASCII NULL is permitted;

      o define any restrictions on allowed path segments, in particular
        whether non-terminal NULL segments are permitted;

      o define the behaviour for "." or ".." path segments; i.e. whether
        they are prohibited, treated as ordinary path segments or
        interpreted in accordance with the relative URL specification
        [7];

      o define any limits of the implementation, including limits on
        path or search string lengths, and limits on the volume of
        headers the server will parse.

   Servers may generate the script URI in any way from the client URI,
   or from any other data (but the behaviour should be documented).

11. Recommendations for scripts

   Scripts should reject unexpected methods (such as DELETE etc.) with
   error 405 Method Not Allowed. If the script does not intend
   processing the PATH_INFO data, then it should reject the request with
   404 Not Found if PATH_INFO is not NULL.

   If the output of a form is being processed, check that CONTENT_TYPE
   is "application/x-www-form-urlencoded" [2].

   If parsing PATH_INFO, PATH_TRANSLATED or SCRIPT_NAME then be careful
   of void path segments ("//") and special path segments ("." and
   ".."). They should either be removed from the path before use in OS
   system calls, or the request should be rejected with 404 Not Found.
   It is very unlikely that any other use could be made of these.

   As it is impossible for the script to determine the client URI that
   initiated this request without knowledge of the specific server in
   use, the script should not return text/html documents containing
   relative URL links without including a  tag in the document.

   When returning headers, the script should try to send the CGI headers




 
INTERNET-DRAFT       Common Gateway Interface - 1.1     15 February 1996


   as soon as possible, and preferably before any HTTP headers. This may
   help reduce the server's memory requirements.