--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
+ "http://www.w3.org/TR/REC-html40/loose.dtd">
+<HTML>
+ <HEAD>
+ <TITLE>Common Gateway Interface - 1.1 *Draft 03* [http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html]
+ </TITLE>
+<!--#if expr="$HTTP_USER_AGENT != /Lynx/" -->
+ <!--#set var="GUI" value="1" -->
+<!--#endif -->
+ <LINK HREF="mailto:Ken.Coar@Golux.Com" rev="revised">
+ <LINK REL="STYLESHEET" HREF="cgip-style-rfc.css" TYPE="text/css">
+ <META name="latexstyle" content="rfc">
+ <META name="author" content="Ken A L Coar">
+ <META name="institute" content="IBM Corporation">
+ <META name="date" content="25 June 1999">
+ <META name="expires" content="Expires 31 December 1999">
+ <META name="document" content="INTERNET-DRAFT">
+ <META name="file" content="<draft-coar-cgi-v11-03.txt>">
+ <META name="group" content="INTERNET-DRAFT">
+<!--
+ There are a lot of BNF fragments in this document. To make it work
+ in all possible browsers (including Lynx, which is used to turn it
+ into text/plain), we handle these by using PREformatted blocks with
+ a universal internal margin of 2, inside one-level DL blocks.
+ -->
+ </HEAD>
+ <BODY>
+ <!--
+ HTML doesn't do paper pagination, so we need to fake it out. Basing
+ our formatting upon RFC2068, there are four (4) lines of header and
+ four (4) lines of footer for each page.
+
+<DIV ALIGN="CENTER">
+ <PRE>
+
+
+
+
+Coar, et al. CGI/1.1 Specification May, 1998
+INTERNET-DRAFT Expires 1 December 1998 [Page 2]
+
+
+ </PRE>
+</DIV>
+ -->
+ <!--
+ The following weirdness wrt non-breaking spaces is to get Lynx
+ (which is barely TABLE-aware) to line the left/right justified
+ text up properly.
+ -->
+ <DIV ALIGN="CENTER">
+ <TABLE WIDTH="100%" CELLPADDING=0 CELLSPACING=0>
+ <TR VALIGN="TOP">
+ <TD ALIGN="LEFT">
+ INTERNET-DRAFT
+ </TD>
+ <TD ALIGN="RIGHT">
+ Ken A L Coar
+ </TD>
+ </TR>
+ <TR VALIGN="TOP">
+ <TD ALIGN="LEFT">
+ draft-coar-cgi-v11-03.{html,txt}
+ </TD>
+ <TD ALIGN="RIGHT">
+ IBM Corporation
+ </TD>
+ </TR>
+ <TR VALIGN="TOP">
+ <TD ALIGN="LEFT">
+
+ </TD>
+ <TD ALIGN="RIGHT">
+ D.R.T. Robinson
+ </TD>
+ </TR>
+ <TR VALIGN="TOP">
+ <TD ALIGN="LEFT">
+
+ </TD>
+ <TD ALIGN="RIGHT">
+ E*TRADE UK Ltd.
+ </TD>
+ </TR>
+ <TR VALIGN="TOP">
+ <TD ALIGN="LEFT">
+
+ </TD>
+ <TD ALIGN="RIGHT">
+ 25 June 1999
+ </TD>
+ </TR>
+ </TABLE>
+ </DIV>
+
+ <H1 ALIGN="CENTER">
+ The WWW Common Gateway Interface
+ <BR>
+ Version 1.1
+ </H1>
+
+<!--#include virtual="I-D-statement" -->
+
+ <H2>
+ <A NAME="Abstract">
+ Abstract
+ </A>
+ </H2>
+ <P>
+ The Common Gateway Interface (CGI) is a simple interface for running
+ external programs, software or gateways under an information server
+ in a platform-independent manner. Currently, the supported information
+ servers are HTTP servers.
+ </P>
+ <P>
+ The interface has been in use by the World-Wide Web since 1993. This
+ specification defines the
+ "current practice" parameters of the
+ 'CGI/1.1' interface developed and documented at the U.S. National
+ Centre for Supercomputing Applications [NCSA-CGI].
+ This document also defines the use of the CGI/1.1 interface
+ on the Unix and AmigaDOS(tm) systems.
+ </P>
+ <P>
+ Discussion of this draft occurs on the CGI-WG mailing list; see the
+ project Web page at
+ <SAMP><URL:<A HREF="http://CGI-Spec.Golux.Com/"
+ >http://CGI-Spec.Golux.Com/</A>></SAMP>
+ for details on the mailing list and the status of the project.
+ </P>
+
+<!--#if expr="$GUI" -->
+ <H2>
+ Revision History
+ </H2>
+ <P>
+ The revision history of this draft is being maintained using Web-based
+ GUI notation, such as struck-through characters and colour-coded
+ sections. The following legend describes how to determine the origin
+ of a particular revision according to the colour of the text:
+ </P>
+ <DL COMPACT>
+ <DT>Black
+ </DT>
+ <DD>Revision 00, released 28 May 1998
+ </DD>
+ <DT>Green
+ </DT>
+ <DD>Revision 01, released 28 December 1998
+ <BR>
+ Major structure change: Section 4, "Request Metadata (Meta-Variables)"
+ was moved entirely under <A HREF="#7.0">Section 7</A>, "Data Input to the
+ CGI Script."
+ Due to the size of this change, it is noted here and the text in its
+ former location does <EM>not</EM> appear as struckthrough. This has
+ caused major <A HREF="#6.0">sections 5</A> and following to decrement
+ by one. Other
+ large text movements are likewise not marked up. References to RFC
+ 1738 were changed to 2396 (1738's replacement).
+ </DD>
+ <DT>Red
+ </DT>
+ <DD>Revision 02, released 2 April, 1999
+ <BR>
+ Added text to <A HREF="#8.3">section 8.3</A> defining correct handling
+ of HTTP/1.1
+ requests using "chunked" Transfer-Encoding. Labelled metavariable
+ names in <A HREF="#8.0">section 8</A> with the appropriate detail section
+ numbers.
+ Clarified allowed usage of <SAMP>Status</SAMP> and
+ <SAMP>Location</SAMP> response header fields. Included new
+ Internet-Draft language.
+ </DD>
+ <DT>Fuchsia
+ </DT>
+ <DD>Revision 03, released 25 June 1999
+ <BR>
+ Changed references from "HTTP" to "Protocol-Specific" for the listing of
+ things like HTTP_ACCEPT. Changed 'entity-body' and 'content-body' to
+ 'message-body.' Added a note that response headers must comply with
+ requirements of the protocol level in use. Added a lot of stuff about
+ security (section 11). Clarified a bunch of productions. Pointed out
+ that zero-length and omitted values are indistinguishable in this
+ specification. Clarified production describing order of fields in
+ script response header. Clarified issues surrounding encoding of
+ data. Acknowledged additional contributors, and changed one of
+ the authors' addresses.
+ </DD>
+ </DL>
+<!--#endif -->
+
+ <H2>
+ <A NAME="Contents">
+ Table of Contents
+ </A>
+ </H2>
+ <DIV ALIGN="CENTER">
+ <PRE>
+ 1 Introduction..............................................<A
+ HREF="#1.0"
+ >TBD</A>
+ 1.1 Purpose................................................<A
+ HREF="#1.1"
+ >TBD</A>
+ 1.2 Requirements...........................................<A
+ HREF="#1.2"
+ >TBD</A>
+ 1.3 Specifications.........................................<A
+ HREF="#1.3"
+ >TBD</A>
+ 1.4 Terminology............................................<A
+ HREF="#1.4"
+ >TBD</A>
+ 2 Notational Conventions and Generic Grammar................<A
+ HREF="#2.0"
+ >TBD</A>
+ 2.1 Augmented BNF..........................................<A
+ HREF="#2.1"
+ >TBD</A>
+ 2.2 Basic Rules............................................<A
+ HREF="#2.2"
+ >TBD</A>
+ 3 Protocol Parameters.......................................<A
+ HREF="#3.0"
+ >TBD</A>
+ 3.1 URL Encoding...........................................<A
+ HREF="#3.1"
+ >TBD</A>
+ 3.2 The Script-URI.........................................<A
+ HREF="#3.2"
+ >TBD</A>
+ 4 Invoking the Script.......................................<A
+ HREF="#4.0"
+ >TBD</A>
+ 5 The CGI Script Command Line...............................<A
+ HREF="#5.0"
+ >TBD</A>
+ 6 Data Input to the CGI Script..............................<A
+ HREF="#6.0"
+ >TBD</A>
+ 6.1 Request Metadata (Metavariables).......................<A
+ HREF="#6.1"
+ >TBD</A>
+ 6.1.1 AUTH_TYPE...........................................<A
+ HREF="#6.1.1"
+ >TBD</A>
+ 6.1.2 CONTENT_LENGTH......................................<A
+ HREF="#6.1.2"
+ >TBD</A>
+ 6.1.3 CONTENT_TYPE........................................<A
+ HREF="#6.1.3"
+ >TBD</A>
+ 6.1.4 GATEWAY_INTERFACE...................................<A
+ HREF="#6.1.4"
+ >TBD</A>
+ 6.1.5 Protocol-Specific Metavariables.....................<A
+ HREF="#6.1.5"
+ >TBD</A>
+ 6.1.6 PATH_INFO...........................................<A
+ HREF="#6.1.6"
+ >TBD</A>
+ 6.1.7 PATH_TRANSLATED.....................................<A
+ HREF="#6.1.7"
+ >TBD</A>
+ 6.1.8 QUERY_STRING........................................<A
+ HREF="#6.1.8"
+ >TBD</A>
+ 6.1.9 REMOTE_ADDR.........................................<A
+ HREF="#6.1.9"
+ >TBD</A>
+ 6.1.10 REMOTE_HOST........................................<A
+ HREF="#6.1.10"
+ >TBD</A>
+ 6.1.11 REMOTE_IDENT.......................................<A
+ HREF="#6.1.11"
+ >TBD</A>
+ 6.1.12 REMOTE_USER........................................<A
+ HREF="#6.1.12"
+ >TBD</A>
+ 6.1.13 REQUEST_METHOD.....................................<A
+ HREF="#6.1.13"
+ >TBD</A>
+ 6.1.14 SCRIPT_NAME........................................<A
+ HREF="#6.1.14"
+ >TBD</A>
+ 6.1.15 SERVER_NAME........................................<A
+ HREF="#6.1.15"
+ >TBD</A>
+ 6.1.16 SERVER_PORT........................................<A
+ HREF="#6.1.16"
+ >TBD</A>
+ 6.1.17 SERVER_PROTOCOL....................................<A
+ HREF="#6.1.17"
+ >TBD</A>
+ 6.1.18 SERVER_SOFTWARE....................................<A
+ HREF="#6.1.18"
+ >TBD</A>
+ 6.2 Request Message-Bodies................................<A
+ HREF="#6.2"
+ >TBD</A>
+ 7 Data Output from the CGI Script...........................<A
+ HREF="#7.0"
+ >TBD</A>
+ 7.1 Non-Parsed Header Output...............................<A
+ HREF="#7.1"
+ >TBD</A>
+ 7.2 Parsed Header Output...................................<A
+ HREF="#7.2"
+ >TBD</A>
+ 7.2.1 CGI header fields...................................<A
+ HREF="#7.2.1"
+ >TBD</A>
+ 7.2.1.1 Content-Type.....................................<A
+ HREF="#7.2.1.1"
+ >TBD</A>
+ 7.2.1.2 Location.........................................<A
+ HREF="#7.2.1.2"
+ >TBD</A>
+ 7.2.1.3 Status...........................................<A
+ HREF="#7.2.1.3"
+ >TBD</A>
+ 7.2.1.4 Extension header fields..........................<A
+ HREF="#7.2.1.3"
+ >TBD</A>
+ 7.2.2 HTTP header fields..................................<A
+ HREF="#7.2.2"
+ >TBD</A>
+ 8 Server Implementation.....................................<A
+ HREF="#8.0"
+ >TBD</A>
+ 8.1 Requirements for Servers...............................<A
+ HREF="#8.1"
+ >TBD</A>
+ 8.1.1 Script-URI..........................................<A
+ HREF="#8.1"
+ >TBD</A>
+ 8.1.2 Request Message-body Handling.......................<A
+ HREF="#8.1.2"
+ >TBD</A>
+ 8.1.3 Required Metavariables..............................<A
+ HREF="#8.1.3"
+ >TBD</A>
+ 8.1.4 Response Compliance.................................<A
+ HREF="#8.1.4"
+ >TBD</A>
+ 8.2 Recommendations for Servers............................<A
+ HREF="#8.2"
+ >TBD</A>
+ 8.3 Summary of Metavariables...............................<A
+ HREF="#8.3"
+ >TBD</A>
+ 9 Script Implementation.....................................<A
+ HREF="#9.0"
+ >TBD</A>
+ 9.1 Requirements for Scripts...............................<A
+ HREF="#9.1"
+ >TBD</A>
+ 9.2 Recommendations for Scripts............................<A
+ HREF="#9.2"
+ >TBD</A>
+ 10 System Specifications....................................<A
+ HREF="#10.0"
+ >TBD</A>
+ 10.1 AmigaDOS..............................................<A
+ HREF="#10.1"
+ >TBD</A>
+ 10.2 Unix..................................................<A
+ HREF="#10.2"
+ >TBD</A>
+ 11 Security Considerations..................................<A
+ HREF="#11.0"
+ >TBD</A>
+ 11.1 Safe Methods..........................................<A
+ HREF="#11.1"
+ >TBD</A>
+ 11.2 HTTP Header Fields Containing Sensitive Information...<A
+ HREF="#11.2"
+ >TBD</A>
+ 11.3 Script Interference with the Server...................<A
+ HREF="#11.3"
+ >TBD</A>
+ 11.4 Data Length and Buffering Considerations..............<A
+ HREF="#11.4"
+ >TBD</A>
+ 11.5 Stateless Processing..................................<A
+ HREF="#11.5"
+ >TBD</A>
+ 12 Acknowledgments..........................................<A
+ HREF="#12.0"
+ >TBD</A>
+ 13 References...............................................<A
+ HREF="#13.0"
+ >TBD</A>
+ 14 Authors' Addresses.......................................<A
+ HREF="#14.0"
+ >TBD</A>
+ </PRE>
+ </DIV>
+
+ <H2>
+ <A NAME="1.0">
+ 1. Introduction
+ </A>
+ </H2>
+
+ <H3>
+ <A NAME="1.1">
+ 1.1. Purpose
+ </A>
+ </H3>
+ <P>
+ Together the HTTP [<A HREF="#[3]">3</A>,<A HREF="#[8]">8</A>] server
+ and the CGI script are responsible
+ for servicing a client
+ request by sending back responses. The client
+ request comprises a Universal Resource Identifier (URI)
+ [<A HREF="#[1]">1</A>], a
+ request method, and various ancillary
+ information about the request
+ provided by the transport mechanism.
+ </P>
+ <P>
+ The CGI defines the abstract parameters, known as
+ metavariables,
+ which describe the client's
+ request. Together with a
+ concrete programmer interface this specifies a platform-independent
+ interface between the script and the HTTP server.
+ </P>
+
+ <H3>
+ <A NAME="1.2">
+ 1.2. Requirements
+ </A>
+ </H3>
+ <P>
+ This specification uses the same words as RFC 1123
+ [<A HREF="#[5]">5</A>] to define the
+ significance of each particular requirement. These are:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <DL>
+ <DT><EM>MUST</EM>
+ </DT>
+ <DD>
+ <P>
+ This word or the adjective 'required' means that the item is an
+ absolute requirement of the specification.
+ </P>
+ </DD>
+ <DT><EM>SHOULD</EM>
+ </DT>
+ <DD>
+ <P>
+ This word or the adjective 'recommended' means that there may
+ exist valid reasons in particular circumstances to ignore this
+ item, but the full implications should be understood and the case
+ carefully weighed before choosing a different course.
+ </P>
+ </DD>
+ <DT><EM>MAY</EM>
+ </DT>
+ <DD>
+ <P>
+ This word or the adjective 'optional' means that this item is
+ truly optional. One vendor may choose to include the item because
+ a particular marketplace requires it or because it enhances the
+ product, for example; another vendor may omit the same item.
+ </P>
+ </DD>
+ </DL>
+ <P>
+ An implementation is not compliant if it fails to satisfy one or more
+ of the 'must' requirements for the protocols it implements. An
+ implementation that satisfies all of the 'must' and all of the
+ 'should' requirements for its features is said to be 'unconditionally
+ compliant'; one that satisfies all of the 'must' requirements but not
+ all of the 'should' requirements for its features is said to be
+ 'conditionally compliant.'
+ </P>
+
+ <H3>
+ <A NAME="1.3">
+ 1.3. Specifications
+ </A>
+ </H3>
+ <P>
+ Not all of the functions and features of the CGI are defined in the
+ main part of this specification. The following phrases are used to
+ describe the features which are not specified:
+ </P>
+ <DL>
+ <DT><EM>system defined</EM>
+ </DT>
+ <DD>
+ <P>
+ The feature may differ between systems, but must be the same for
+ different implementations using the same system. A system will
+ usually identify a class of operating-systems. Some systems are
+ defined in
+ <A HREF="#10.0"
+ >section 10</A> of this document.
+ New systems may be defined
+ by new specifications without revision of this document.
+ </P>
+ </DD>
+ <DT><EM>implementation defined</EM>
+ </DT>
+ <DD>
+ <P>
+ The behaviour of the feature may vary from implementation to
+ implementation, but a particular implementation must document its
+ behaviour.
+ </P>
+ </DD>
+ </DL>
+
+ <H3>
+ <A NAME="1.4">
+ 1.4. Terminology
+ </A>
+ </H3>
+ <P>
+ This specification uses many terms defined in the HTTP/1.1
+ specification [<A HREF="#[8]">8</A>]; however, the following terms are
+ used here in a
+ sense which may not accord with their definitions in that document,
+ or with their common meaning.
+ </P>
+
+ <DL>
+ <DT><EM>metavariable</EM>
+ </DT>
+ <DD>
+ <P>
+ A named parameter that carries information from the server to the
+ script. It is not necessarily a variable in the operating-system's
+ environment, although that is the most common implementation.
+ </P>
+ </DD>
+
+ <DT><EM>script</EM>
+ </DT>
+ <DD>
+ <P>
+ The software which is invoked by the server <EM>via</EM> this
+ interface. It
+ need not be a standalone program, but could be a
+ dynamically-loaded or shared library, or even a subroutine in the
+ server. It <EM>may</EM> be a set of statements
+ interpreted at run-time, as the term 'script' is frequently
+ understood, but that is not a requirement and within the context
+ of this specification the term has the broader definition stated.
+ </P>
+ </DD>
+ <DT><EM>server</EM>
+ </DT>
+ <DD>
+ <P>
+ The application program which invokes the script in order to service
+ requests.
+ </P>
+ </DD>
+ </DL>
+
+ <H2>
+ <A NAME="2.0">
+ 2. Notational Conventions and Generic Grammar
+ </A>
+ </H2>
+
+ <H3>
+ <A NAME="2.1">
+ 2.1. Augmented BNF
+ </A>
+ </H3>
+ <P>
+ All of the mechanisms specified in this document are described in
+ both prose and an augmented Backus-Naur Form (BNF) similar to that
+ used by RFC 822 [<A HREF="#[6]">6</A>]. This augmented BNF contains
+ the following constructs:
+ </P>
+ <DL>
+ <DT>name = definition
+ </DT>
+ <DD>
+ <P>
+ The
+ definition by the equal character ("="). Whitespace is only
+ significant in that continuation lines of a definition are
+ indented.
+ </P>
+ </DD>
+ <DT>"literal"
+ </DT>
+ <DD>
+ <P>
+ Quotation marks (") surround literal text, except for a literal
+ quotation mark, which is surrounded by angle-brackets ("<" and ">").
+ Unless stated otherwise, the text is case-sensitive.
+ </P>
+ </DD>
+ <DT>rule1 | rule2
+ </DT>
+ <DD>
+ <P>
+ Alternative rules are separated by a vertical bar ("|").
+ </P>
+ </DD>
+ <DT>(rule1 rule2 rule3)
+ </DT>
+ <DD>
+ <P>
+ Elements enclosed in parentheses are treated as a single element.
+ </P>
+ </DD>
+ <DT>*rule
+ </DT>
+ <DD>
+ <P>
+ A rule preceded by an asterisk ("*") may have zero or more
+ occurrences. A rule preceded by an integer followed by an asterisk
+ must occur at least the specified number of times.
+ </P>
+ </DD>
+ <DT>[rule]
+ </DT>
+ <DD>
+ <P>
+ An element enclosed in square
+ brackets ("[" and "]") is optional.
+ </P>
+ </DD>
+ </DL>
+
+ <H3>
+ <A NAME="2.2">
+ 2.2. Basic Rules
+ </A>
+ </H3>
+ <P>
+ The following rules are used throughout this specification to
+ describe basic parsing constructs.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ alpha = lowalpha | hialpha
+ alphanum = alpha | digit
+ lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h"
+ | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p"
+ | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
+ | "y" | "z"
+ hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H"
+ | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P"
+ | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
+ | "Y" | "Z"
+ digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"
+ | "8" | "9"
+ hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a"
+ | "b" | "c" | "d" | "e" | "f"
+ escaped = "%" hex hex
+ OCTET = <any 8-bit sequence of data>
+ CHAR = <any US-ASCII character (octets 0 - 127)>
+ CTL = <any US-ASCII control character
+ (octets 0 - 31) and DEL (127)>
+ CR = <US-ASCII CR, carriage return (13)>
+ LF = <US-ASCII LF, linefeed (10)>
+ SP = <US-ASCII SP, space (32)>
+ HT = <US-ASCII HT, horizontal tab (9)>
+ NL = CR | LF
+ LWSP = SP | HT | NL
+ tspecial = "(" | ")" | "@" | "," | ";" | ":" | "\" | <">
+ | "/" | "[" | "]" | "?" | "<" | ">" | "{" | "}"
+ | SP | HT | NL
+ token = 1*<any CHAR except CTLs or tspecials>
+ quoted-string = ( <"> *qdtext <"> ) | ( "<" *qatext ">")
+ qdtext = <any CHAR except <"> and CTLs but including LWSP>
+ qatext = <any CHAR except "<", ">" and CTLs but
+ including LWSP>
+ mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
+ unreserved = alphanum | mark
+ reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" |
+ "$" | ","
+ uric = reserved | unreserved | escaped
+ </PRE>
+ <P>
+ Note that newline (NL) need not be a single character, but can be a
+ character sequence.
+ </P>
+
+ <H2>
+ <A NAME="3.0">
+ 3. Protocol Parameters
+ </A>
+ </H2>
+
+ <H3>
+ <A NAME="3.1">
+ 3.1. URL Encoding
+ </A>
+ </H3>
+ <P>
+ Some variables and constructs used here are described as being
+ 'URL-encoded'. This encoding is described in section
+ 2 of RFC
+ 2396
+ [<A HREF="#[4]">4</A>].
+ </P>
+ <P>
+ An alternate "shortcut" encoding for representing the space
+ character exists and is in common use. Scripts MUST be prepared to
+ recognise both '+' and '%20' as an encoded space in a
+ URL-encoded value.
+ </P>
+ <P>
+ Note that some unsafe characters may have different semantics if
+ they are encoded. The definition of which characters are unsafe
+ depends on the context.
+ For example, the following two URLs do not
+ necessarily refer to the same resource:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ http://somehost.com/somedir%2Fvalue
+ http://somehost.com/somedir/value
+ </PRE>
+ <P>
+ See section
+ 2 of RFC
+ 2396 [<A HREF="#[4]">4</A>]
+ for authoritative treatment of this issue.
+ </P>
+
+ <H3>
+ <A NAME="3.2">
+ 3.2. The Script-URI
+ </A>
+ </H3>
+ <P>
+ The 'Script-URI' is defined as the URI of the resource identified
+ by the metavariables. Often,
+ this URI will be the same as
+ the URI requested by the client (the 'Client-URI'); however, it need
+ not be. Instead, it could be a URI invented by the server, and so it
+ can only be used in the context of the server and its CGI interface.
+ </P>
+ <P>
+ The Script-URI has the syntax of generic-RL as defined in section 2.1
+ of RFC 1808 [<A HREF="#[7]">7</A>], with the exception that object
+ parameters and
+ fragment identifiers are not permitted:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ <scheme>://<host><port>/<path>?<query>
+ </PRE>
+ <P>
+ The various components of the
+ Script-URI
+ are defined by some of the
+ metavariables (see
+ <A HREF="#4.0">section 4</A>
+ below);
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ script-uri = protocol "://" SERVER_NAME ":" SERVER_PORT enc-script
+ enc-path-info "?" QUERY_STRING
+ </PRE>
+ <P>
+ where 'protocol' is obtained
+ from SERVER_PROTOCOL, 'enc-script' is a
+ URL-encoded version of SCRIPT_NAME and 'enc-path-info' is a
+ URL-encoded version of PATH_INFO. See
+ <A HREF="#4.6">section 4.6</A> for more information about the PATH_INFO
+ metavariable.
+ </P>
+ <P>
+ Note that the scheme and the protocol are <EM>not</EM> identical;
+ for instance, a resource accessed <EM>via</EM> an SSL mechanism
+ may have a Client-URI with a scheme of "<SAMP>https</SAMP>"
+ rather than "<SAMP>http</SAMP>". CGI/1.1 provides no means
+ for the script to reconstruct this, and therefore
+ the Script-URI includes the base protocol used.
+ </P>
+
+ <H2>
+ <A NAME="4.0">
+ 4. Invoking the Script
+ </A>
+ </H2>
+ <P>
+ The
+ script is invoked in a system defined manner. Unless specified
+ otherwise, the file containing the script will be invoked as an
+ executable program.
+ </P>
+
+ <H2>
+ <A NAME="5.0">
+ 5. The CGI Script Command Line
+ </A>
+ </H2>
+ <P>
+ Some systems support a method for supplying an array of strings to
+ the CGI script. This is only used in the case of an 'indexed' query.
+ This is identified by a "GET" or "HEAD" HTTP request with a URL
+ query
+ string not containing any unencoded "=" characters. For such a
+ request,
+ servers SHOULD parse the search string
+ into words, using the following rules:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ search-string = search-word *( "+" search-word )
+ search-word = 1*schar
+ schar = xunreserved | escaped | xreserved
+ xunreserved = alpha | digit | xsafe | extra
+ xsafe = "$" | "-" | "_" | "."
+ xreserved = ";" | "/" | "?" | ":" | "@" | "&"
+ </PRE>
+ <P>
+ After parsing, each word is URL-decoded, optionally encoded in a
+ system defined manner,
+ and then the argument list is set to the list
+ of words.
+ </P>
+ <P>
+ If the server cannot create any part of the argument list, then the
+ server SHOULD NOT generate any command line information. For example, the
+ number of arguments may be greater than operating system or server
+ limitations permit, or one of the words may not be representable as an
+ argument.
+ </P>
+ <P>
+ Scripts SHOULD check to see if the QUERY_STRING value contains an
+ unencoded "=" character, and SHOULD NOT use the command line arguments
+ if it does.
+ </P>
+
+ <H2>
+ <A NAME="6.0">
+ 6. Data Input to the CGI Script
+ </A>
+ </H2>
+ <P>
+ Information about a request comes from two different sources: the
+ request header, and any associated
+ message-body.
+ Servers MUST
+ make portions of this information available to
+ scripts.
+ </P>
+
+ <H3>
+ <A NAME="6.1">
+ 6.1. Request Metadata
+ (Metavariables)
+ </A>
+ </H3>
+ <P>
+ Each CGI server
+ implementation MUST define a mechanism
+ to pass data about the request from
+ the server to the script.
+ The metavariables containing these
+ data
+ are accessed by the script in a system
+ defined manner.
+ The
+ representation of the characters in the
+ metavariables is
+ system defined.
+ </P>
+ <P>
+ This specification does not distinguish between the representation of
+ null values and missing ones. Whether null or missing values
+ (such as a query component of "?" or "", respectively) are represented
+ by undefined metavariables or by metavariables with values of "" is
+ implementation-defined.
+ </P>
+ <P>
+ Case is not significant in the
+ metavariable
+ names, in that there cannot be two
+ different variables
+ whose names differ in case only. Here they are
+ shown using a canonical representation of capitals plus underscore
+ ("_"). The actual representation of the names is system defined; for
+ a particular system the representation MAY be defined differently
+ than this.
+ </P>
+ <P>
+ Metavariable
+ values MUST be
+ considered case-sensitive except as noted
+ otherwise.
+ </P>
+ <P>
+ The canonical
+ metavariables
+ defined by this specification are:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ AUTH_TYPE
+ CONTENT_LENGTH
+ CONTENT_TYPE
+ GATEWAY_INTERFACE
+ PATH_INFO
+ PATH_TRANSLATED
+ QUERY_STRING
+ REMOTE_ADDR
+ REMOTE_HOST
+ REMOTE_IDENT
+ REMOTE_USER
+ REQUEST_METHOD
+ SCRIPT_NAME
+ SERVER_NAME
+ SERVER_PORT
+ SERVER_PROTOCOL
+ SERVER_SOFTWARE
+ </PRE>
+ <P>
+ Metavariables with names beginning with the protocol name (<EM>e.g.</EM>,
+ "HTTP_ACCEPT") are also canonical in their description of request header
+ fields. The number and meaning of these fields may change independently
+ of this specification. (See also <A HREF="#6.1.5">section 6.1.5</A>.)
+ </P>
+
+ <H4>
+ <A NAME="6.1.1">
+ 6.1.1. AUTH_TYPE
+ </A>
+ </H4>
+ <P>
+ This variable is specific to requests made
+ <EM>via</EM> the
+ "<CODE>http</CODE>"
+ scheme.
+ </P>
+ <P>
+ If the Script-URI
+ required access authentication for external
+ access, then the server
+ MUST set
+ the value of
+ this variable
+ from the '<SAMP>auth-scheme</SAMP>' token in
+ the request's "<SAMP>Authorization</SAMP>" header
+ field.
+ Otherwise
+ it is
+ set to NULL.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ AUTH_TYPE = "" | auth-scheme
+ auth-scheme = "Basic" | "Digest" | token
+ </PRE>
+ <P>
+ HTTP access authentication schemes are described in section 11 of the
+ HTTP/1.1 specification [<A HREF="#[8]">8</A>]. The auth-scheme is
+ not case-sensitive.
+ </P>
+ <P>
+ Servers
+ MUST
+ provide this metavariable
+ to scripts if the request
+ header included an "<SAMP>Authorization</SAMP>" field
+ that was authenticated.
+ </P>
+
+ <H4>
+ <A NAME="6.1.2">
+ 6.1.2. CONTENT_LENGTH
+ </A>
+ </H4>
+ <P>
+ This
+ metavariable
+ is set to the
+ size of the message-body
+ entity attached to the request, if any, in decimal
+ number of octets. If no data are attached, then this
+ metavariable
+ is either NULL or not
+ defined. The syntax is
+ the same as for
+ the HTTP "<SAMP>Content-Length</SAMP>" header field (section 14.14, HTTP/1.1
+ specification [<A HREF="#[8]">8</A>]).
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ CONTENT_LENGTH = "" | 1*digit
+ </PRE>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts if the request
+ was accompanied by a
+ message-body entity.
+ </P>
+
+ <H4>
+ <A NAME="6.1.3">
+ 6.1.3. CONTENT_TYPE
+ </A>
+ </H4>
+ <P>
+ If the request includes a
+ message-body,
+ CONTENT_TYPE is set
+ to
+ the Internet Media Type
+ [<A HREF="#[9]">9</A>] of the attached
+ entity if the type was provided <EM>via</EM>
+ a "<SAMP>Content-type</SAMP>" field in the
+ request header, or if the server can determine it in the absence
+ of a supplied "<SAMP>Content-type</SAMP>" field. The syntax is the
+ same as for the HTTP
+ "<SAMP>Content-Type</SAMP>" header field.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ CONTENT_TYPE = "" | media-type
+ media-type = type "/" subtype *( ";" parameter)
+ type = token
+ subtype = token
+ parameter = attribute "=" value
+ attribute = token
+ value = token | quoted-string
+ </PRE>
+ <P>
+ The type, subtype,
+ and parameter attribute names are not
+ case-sensitive. Parameter values MAY be case sensitive.
+ Media types and their use in HTTP are described
+ in section 3.7 of the
+ HTTP/1.1 specification [<A HREF="#[8]">8</A>].
+ </P>
+ <P>
+ Example:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ application/x-www-form-urlencoded
+ </PRE>
+ <P>
+ There is no default value for this variable. If and only if it is
+ unset, then the script MAY attempt to determine the media type from
+ the data received. If the type remains unknown, then
+ the script MAY choose to either assume a
+ content-type of
+ <SAMP>application/octet-stream</SAMP>
+ or reject the request with a 415 ("Unsupported Media Type")
+ error. See <A HREF="#7.2.1.3">section 7.2.1.3</A>
+ for more information about returning error status values.
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts if
+ a "<SAMP>Content-Type</SAMP>" field was present
+ in the original request header. If the server receives a request
+ with an attached entity but no "<SAMP>Content-Type</SAMP>"
+ header field, it MAY attempt to
+ determine the correct datatype, or it MAY omit this
+ metavariable when
+ communicating the request information to the script.
+ </P>
+
+ <H4>
+ <A NAME="6.1.4">
+ 6.1.4. GATEWAY_INTERFACE
+ </A>
+ </H4>
+ <P>
+ This
+ metavariable
+ is set to
+ the dialect of CGI being used
+ by the server to communicate with the script.
+ Syntax:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ GATEWAY_INTERFACE = "CGI" "/" major "." minor
+ major = 1*digit
+ minor = 1*digit
+ </PRE>
+ <P>
+ Note that the major and minor numbers are treated as separate
+ integers and hence each may be
+ more than a single
+ digit. Thus CGI/2.4 is a lower version than CGI/2.13 which in turn
+ is lower than CGI/12.3. Leading zeros in either
+ the major or the minor number MUST be ignored by scripts and
+ SHOULD NOT be generated by servers.
+ </P>
+ <P>
+ This document defines the 1.1 version of the CGI interface
+ ("CGI/1.1").
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.5">
+ 6.1.5. Protocol-Specific Metavariables
+ </A>
+ </H4>
+ <P>
+ These metavariables are specific to
+ the protocol
+ <EM>via</EM> which the request is made.
+ Interpretation of these variables depends on the value of
+ the
+ SERVER_PROTOCOL
+ metavariable
+ (see
+ <A HREF="#6.1.17">section 6.1.17</A>).
+ </P>
+ <P>
+ Metavariables
+ with names beginning with "HTTP_" contain
+ values from the request header, if the
+ scheme used was HTTP.
+ Each
+ HTTP header field name is converted to upper case, has all occurrences of
+ "-" replaced with "_",
+ and has "HTTP_" prepended to form
+ the metavariable name.
+ Similar transformations are applied for other
+ protocols.
+ The header data MAY be presented as sent
+ by the client, or MAY be rewritten in ways which do not change its
+ semantics. If multiple header fields with the same field-name are received
+ then the server
+ MUST rewrite them as though they
+ had been received as a single header field having the same
+ semantics before being represented in a
+ metavariable.
+ Similarly, a header field that is received on more than one line
+ MUST be merged into a single line. The server MUST, if necessary,
+ change the representation of the data (for example, the character
+ set) to be appropriate for a CGI
+ metavariable.
+ <!-- ###NOTE: See if 2068 describes this thoroughly, and
+ point there if so. -->
+ </P>
+ <P>
+ Servers are
+ not required to create
+ metavariables for all
+ the request
+ header fields that they
+ receive. In particular,
+ they MAY
+ decline to make available any
+ header fields carrying authentication information, such as
+ "<SAMP>Authorization</SAMP>", or
+ which are available to the script
+ <EM>via</EM> other metavariables,
+ such as "<SAMP>Content-Length</SAMP>" and "<SAMP>Content-Type</SAMP>".
+ </P>
+
+ <H4>
+ <A NAME="6.1.6">
+ 6.1.6. PATH_INFO
+ </A>
+ </H4>
+ <P>
+ The PATH_INFO
+ metavariable
+ specifies
+ a path to be interpreted by the CGI script. It identifies the
+ resource or sub-resource to be returned
+ by the CGI
+ script, and it is derived from the portion
+ of the URI path following the script name but preceding
+ any query data.
+ The syntax
+ and semantics are similar to a decoded HTTP URL
+ 'path' token
+ (defined in
+ RFC 2396
+ [<A HREF="#[4]">4</A>]), with the exception
+ that a PATH_INFO of "/"
+ represents a single void path segment.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ PATH_INFO = "" | ( "/" path )
+ path = segment *( "/" segment )
+ segment = *pchar
+ pchar = <any CHAR except "/">
+ </PRE>
+ <P>
+ The PATH_INFO string is the trailing part of the <path> component of
+ the Script-URI
+ (see <A HREF="#3.2">section 3.2</A>)
+ that follows the SCRIPT_NAME
+ portion of the path.
+ </P>
+ <P>
+ Servers MAY impose their own restrictions and
+ limitations on what values they will accept for PATH_INFO, and MAY
+ reject or edit any values they
+ consider objectionable before passing
+ them to the script.
+ </P>
+ <P>
+ Servers MUST make this URI component available
+ to CGI scripts. The PATH_INFO
+ value is case-sensitive, and the
+ server MUST preserve the case of the PATH_INFO element of the URI
+ when making it available to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.7">
+ 6.1.7. PATH_TRANSLATED
+ </A>
+ </H4>
+ <P>
+ PATH_TRANSLATED is derived by taking any path-info component of the
+ request URI (see
+ <A HREF="#6.1.6">section 6.1.6</A>), decoding it
+ (see <A HREF="#3.1">section 3.1</A>), parsing it as a URI in its own
+ right, and performing any virtual-to-physical
+ translation appropriate to map it onto the
+ server's document repository structure.
+ If the request URI includes no path-info
+ component, the PATH_TRANSLATED metavariable SHOULD NOT be defined.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ PATH_TRANSLATED = *CHAR
+ </PRE>
+ <P>
+ For a request such as the following:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ http://somehost.com/cgi-bin/somescript/this%2eis%2epath%2einfo
+ </PRE>
+ <P>
+ the PATH_INFO component would be decoded, and the result
+ parsed as though it were a request for the following:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ http://somehost.com/this.is.the.path.info
+ </PRE>
+ <P>
+ This would then be translated to a
+ location in the server's document repository,
+ perhaps a filesystem path something
+ like this:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ /usr/local/www/htdocs/this.is.the.path.info
+ </PRE>
+ <P>
+ The result of the translation is the value of PATH_TRANSLATED.
+ </P>
+ <P>
+ The value of PATH_TRANSLATED may or may not map to a valid
+ repository
+ location.
+ Servers MUST preserve the case of the path-info
+ segment if and only if the underlying
+ repository
+ supports case-sensitive
+ names. If the
+ repository
+ is only case-aware, case-preserving, or case-blind
+ with regard to
+ document names,
+ servers are not required to preserve the
+ case of the original segment through the translation.
+ </P>
+ <P>
+ The
+ translation
+ algorithm the server uses to derive PATH_TRANSLATED is
+ implementation defined; CGI scripts which use this variable may
+ suffer limited portability.
+ </P>
+ <P>
+ Servers SHOULD provide this metavariable
+ to scripts if and only if the request URI includes a
+ path-info component.
+ </P>
+
+ <H4>
+ <A NAME="6.1.8">
+ 6.1.8. QUERY_STRING
+ </A>
+ </H4>
+ <P>
+ A URL-encoded
+ string; the <query> part of the
+ Script-URI.
+ (See
+ <A HREF="#3.2">section 3.2</A>.)
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ QUERY_STRING = query-string
+ query-string = *uric
+ </PRE>
+ <P>
+ The URL syntax for a query
+ string is described in
+ section 3 of
+ RFC 2396
+ [<A HREF="#[4]">4</A>].
+ </P>
+ <P>
+ Servers MUST supply this value to scripts.
+ The QUERY_STRING value is case-sensitive.
+ If the Script-URI does not include a query component,
+ the QUERY_STRING metavariable MUST be defined as an empty string ("").
+ </P>
+
+ <H4>
+ <A NAME="6.1.9">
+ 6.1.9. REMOTE_ADDR
+ </A>
+ </H4>
+ <P>
+ The IP address of the client
+ sending the request to the server. This
+ is not necessarily that of the user
+ agent
+ (such as if the request came through a proxy).
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ REMOTE_ADDR = hostnumber
+ hostnumber = ipv4-address | ipv6-address
+ </PRE>
+ <P>
+ The definitions of <SAMP>ipv4-address</SAMP> and <SAMP>ipv6-address</SAMP>
+ are provided in Appendix B of RFC 2373 [<A HREF="#[13]">13</A>].
+ </P>
+ <P>
+ Servers MUST supply this value to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.10">
+ 6.1.10. REMOTE_HOST
+ </A>
+ </H4>
+ <P>
+ The fully qualified domain name of the
+ client sending the request to
+ the server, if available, otherwise NULL.
+ (See <A HREF="#6.1.9">section 6.1.9</A>.)
+ Fully qualified domain names take the form as described in
+ section 3.5 of RFC 1034 [<A HREF="#[10]">10</A>] and section 2.1 of
+ RFC 1123 [<A HREF="#[5]">5</A>]. Domain names are not case sensitive.
+ </P>
+ <P>
+ Servers SHOULD provide this information to
+ scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.11">
+ 6.1.11. REMOTE_IDENT
+ </A>
+ </H4>
+ <P>
+ The identity information reported about the connection by a
+ RFC 1413 [<A HREF="#[11]">11</A>] request to the remote agent, if
+ available. Servers
+ MAY choose not
+ to support this feature, or not to request the data
+ for efficiency reasons.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ REMOTE_IDENT = *CHAR
+ </PRE>
+ <P>
+ The data returned
+ may be used for authentication purposes, but the level
+ of trust reposed in them should be minimal.
+ </P>
+ <P>
+ Servers MAY supply this information to scripts if the
+ RFC1413 [<A HREF="#[11]">11</A>] lookup is performed.
+ </P>
+
+ <H4>
+ <A NAME="6.1.12">
+ 6.1.12. REMOTE_USER
+ </A>
+ </H4>
+ <P>
+ If the request required authentication using the "Basic"
+ mechanism (<EM>i.e.</EM>, the AUTH_TYPE
+ metavariable is set
+ to "Basic"), then the value of the REMOTE_USER
+ metavariable is set to the
+ user-ID supplied. In all other cases
+ the value of this metavariable
+ is undefined.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ REMOTE_USER = *OCTET
+ </PRE>
+ <P>
+ This variable is specific to requests made <EM>via</EM> the
+ HTTP protocol.
+ </P>
+ <P>
+ Servers SHOULD provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.13">
+ 6.1.13. REQUEST_METHOD
+ </A>
+ </H4>
+ <P>
+ The REQUEST_METHOD
+ metavariable
+ is set to the
+ method with which the request was made, as described in section
+ 5.1.1 of the HTTP/1.0 specification [<A HREF="#[3]">3</A>] and
+ section 5.1.1 of the
+ HTTP/1.1 specification [<A HREF="#[8]">8</A>].
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ REQUEST_METHOD = http-method
+ http-method = "GET" | "HEAD" | "POST" | "PUT" | "DELETE"
+ | "OPTIONS" | "TRACE" | extension-method
+ extension-method = token
+ </PRE>
+ <P>
+ The method is case sensitive.
+ CGI/1.1 servers MAY choose to process some methods
+ directly rather than passing them to scripts.
+ </P>
+ <P>
+ This variable is specific to requests made with HTTP.
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.14">
+ 6.1.14. SCRIPT_NAME
+ </A>
+ </H4>
+ <P>
+ The SCRIPT_NAME
+ metavariable
+ is
+ set to a URL path that could identify the CGI script (rather than the
+ script's
+ output). The syntax and semantics are identical to a
+ decoded HTTP URL 'path' token
+ (see RFC 2396
+ [<A HREF="#[4]">4</A>]).
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ SCRIPT_NAME = "" | ( "/" [ path ] )
+ </PRE>
+ <P>
+ The SCRIPT_NAME string is some leading part of the <path> component
+ of the Script-URI derived in some
+ implementation defined manner.
+ No PATH_INFO or QUERY_STRING segments
+ (see sections <A HREF="#6.1.6">6.1.6</A> and
+ <A HREF="#6.1.8">6.1.8</A>) are included
+ in the SCRIPT_NAME value.
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.15">
+ 6.1.15. SERVER_NAME
+ </A>
+ </H4>
+ <P>
+ The SERVER_NAME
+ metavariable
+ is set to the
+ name of the
+ server, as
+ derived from the <host> part of the
+ Script-URI
+ (see <A HREF="#3.2">section 3.2</A>).
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ SERVER_NAME = hostname | hostnumber
+ </PRE>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.16">
+ 6.1.16. SERVER_PORT
+ </A>
+ </H4>
+ <P>
+ The SERVER_PORT
+ metavariable
+ is set to the
+ port on which the
+ request was received, as used in the <port>
+ part of the Script-URI.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ SERVER_PORT = 1*digit
+ </PRE>
+ <P>
+ If the <port> portion of the script-URI is blank, the actual
+ port number upon which the request was received MUST be supplied.
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.17">
+ 6.1.17. SERVER_PROTOCOL
+ </A>
+ </H4>
+ <P>
+ The SERVER_PROTOCOL
+ metavariable
+ is set to
+ the
+ name and revision of the information protocol with which
+ the
+ request
+ arrived. This is not necessarily the same as the protocol version used by
+ the server in its response to the client.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ SERVER_PROTOCOL = HTTP-Version | extension-version
+ | extension-token
+ HTTP-Version = "HTTP" "/" 1*digit "." 1*digit
+ extension-version = protocol "/" 1*digit "." 1*digit
+ protocol = 1*( alpha | digit | "+" | "-" | "." )
+ extension-token = token
+ </PRE>
+ <P>
+ 'protocol' is a version of the <scheme> part of the
+ Script-URI, but is
+ not identical to it. For example, the scheme of a request may be
+ "<SAMP>https</SAMP>" while the protocol remains "<SAMP>http</SAMP>".
+ The protocol is not case sensitive, but
+ by convention, 'protocol' is in
+ upper case.
+ </P>
+ <P>
+ A well-known extension token value is "INCLUDED",
+ which signals that the current document is being included as part of
+ a composite document, rather than being the direct target of the
+ client request.
+ </P>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H4>
+ <A NAME="6.1.18">
+ 6.1.18. SERVER_SOFTWARE
+ </A>
+ </H4>
+ <P>
+ The SERVER_SOFTWARE
+ metavariable
+ is set to the
+ name and version of the information server software answering the
+ request (and running the gateway).
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ SERVER_SOFTWARE = 1*product
+ product = token [ "/" product-version ]
+ product-version = token
+ </PRE>
+ <P>
+ Servers MUST provide this metavariable
+ to scripts.
+ </P>
+
+ <H3>
+ <A NAME="6.2">
+ 6.2. Request Message-Bodies
+ </A>
+ </H3>
+ <P>
+ As there may be a data entity attached to the request, there MUST be
+ a system defined method for the script to read
+ these data. Unless
+ defined otherwise, this will be <EM>via</EM> the 'standard input' file
+ descriptor.
+ </P>
+ <P>
+ If the CONTENT_LENGTH value (see <A HREF="#6.1.2">section 6.1.2</A>)
+ is non-NULL, the server MUST supply at least that many bytes to
+ scripts on the standard input stream.
+ Scripts are
+ not obliged to read the data.
+ Servers MAY signal an EOF condition after CONTENT_LENGTH bytes have been
+ read, but are
+ not obligated to do so. Therefore, scripts
+ MUST NOT
+ attempt to read more than CONTENT_LENGTH bytes, even if more data
+ are available.
+ </P>
+ <P>
+ For non-parsed header (NPH) scripts (see
+ <A HREF="#7.1">section 7.1</A>
+ below),
+ servers SHOULD
+ attempt to ensure that the data
+ supplied to the script are precisely
+ as supplied by the client and unaltered by
+ the server.
+ </P>
+ <P>
+ <A HREF="#8.1.2">Section 8.1.2</A> describes the requirements of
+ servers with regard to requests that include
+ message-bodies.
+ </P>
+
+ <H2>
+ <A NAME="7.0">
+ 7. Data Output from the CGI Script
+ </A>
+ </H2>
+ <P>
+ There MUST be a system defined method for the script to send data
+ back to the server or client; a script MUST always return some data.
+ Unless defined otherwise, this will be <EM>via</EM> the 'standard
+ output' file descriptor.
+ </P>
+ <P>
+ There are two forms of output that scripts can supply to servers: non-parsed
+ header (NPH) output, and parsed header output.
+ Servers MUST support parsed header
+ output and MAY support NPH output. The method of
+ distinguishing between the two
+ types of output (or scripts) is implementation defined.
+ </P>
+ <P>
+ Servers MAY implement a timeout period within which data must be
+ received from scripts. If a server implementation defines such
+ a timeout and receives no data from a script within the timeout
+ period, the server MAY terminate the script process and SHOULD
+ abort the client request with
+ either a
+ '504 Gateway Timed Out' or a
+ '500 Internal Server Error' response.
+ </P>
+
+ <H3>
+ <A NAME="7.1">
+ 7.1. Non-Parsed Header Output
+ </A>
+ </H3>
+ <P>
+ Scripts using the NPH output form
+ MUST return a complete HTTP response message, as described
+ in Section 6 of the HTTP specifications
+ [<A HREF="#[3]">3</A>,<A HREF="#[8]">8</A>].
+ NPH scripts
+ MUST use the SERVER_PROTOCOL variable to determine the appropriate format
+ for a response.
+ </P>
+ <P>
+ Servers
+ SHOULD attempt to ensure that the script output is sent
+ directly to the client, with minimal
+ internal and no transport-visible
+ buffering.
+ </P>
+
+ <H3>
+ <A NAME="7.2">
+ 7.2. Parsed Header Output
+ </A>
+ </H3>
+ <P>
+ Scripts using the parsed header output form MUST supply
+ a CGI response message to the server
+ as follows:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ CGI-Response = *optional-field CGI-Field *optional-field NL [ Message-Body ]
+ optional-field = ( CGI-Field | HTTP-Field )
+ CGI-Field = Content-type
+ | Location
+ | Status
+ | extension-header
+ </PRE>
+ <P><!-- ##### If HTTP defines x-headers, remove ours except x-cgi- -->
+ The response comprises a header and a body, separated by a blank line.
+ The body may be NULL.
+ The header fields are either CGI header fields to be interpreted by
+ the server, or HTTP header fields
+ to be included in the response returned
+ to the client
+ if the request method is HTTP. At least one
+ CGI-Field MUST be
+ supplied, but no CGI field name may be used more than once
+ in a response.
+ If a body is supplied, then a "<SAMP>Content-type</SAMP>"
+ header field MUST be
+ supplied by the script,
+ otherwise the script MUST send a "<SAMP>Location</SAMP>"
+ or "<SAMP>Status</SAMP>" header field. If a
+ <SAMP>Location</SAMP> CGI-Field
+ is returned, then the script MUST NOT supply
+ any HTTP-Fields.
+ </P>
+ <P>
+ Each header field in a CGI-Response MUST be specified on a single line;
+ CGI/1.1 does not support continuation lines.
+ </P>
+
+ <H4>
+ <A NAME="7.2.1">
+ 7.2.1. CGI header fields
+ </A>
+ </H4>
+ <P>
+ The CGI header fields have the generic syntax:
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ generic-field = field-name ":" [ field-value ] NL
+ field-name = token
+ field-value = *( field-content | LWSP )
+ field-content = *( token | tspecial | quoted-string )
+ </PRE>
+ <P>
+ The field-name is not case sensitive; a NULL field value is
+ equivalent to the header field not being sent.
+ </P>
+
+ <H4>
+ <A NAME="7.2.1.1">
+ 7.2.1.1. Content-Type
+ </A>
+ </H4>
+ <P>
+ The Internet Media Type [<A HREF="#[9]">9</A>] of the entity
+ body, which is to be sent unmodified to the client.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ Content-Type = "Content-Type" ":" media-type NL
+ </PRE>
+ <P>
+ This is actually an HTTP-Field
+ rather than a CGI-Field, but
+ it is listed here because of its importance in the CGI dialogue as
+ a member of the "one of these is required" set of header
+ fields.
+ </P>
+
+ <H4>
+ <A NAME="7.2.1.2">
+ 7.2.1.2. Location
+ </A>
+ </H4>
+ <P>
+ This is used to specify to the server that the script is returning a
+ reference to a document rather than an actual document.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ Location = "Location" ":"
+ ( fragment-URI | rel-URL-abs-path ) NL
+ fragment-URI = URI [ # fragmentid ]
+ URI = scheme ":" *qchar
+ fragmentid = *qchar
+ rel-URL-abs-path = "/" [ hpath ] [ "?" query-string ]
+ hpath = fpsegment *( "/" psegment )
+ fpsegment = 1*hchar
+ psegment = *hchar
+ hchar = alpha | digit | safe | extra
+ | ":" | "@" | "& | "="
+ </PRE>
+ <P>
+ The Location
+ value is either an absolute URI with optional fragment,
+ as defined in RFC 1630 [<A HREF="#[1]">1</A>], or an absolute path
+ within the server's URI space (<EM>i.e.</EM>,
+ omitting the scheme and network-related fields) and optional
+ query-string. If an absolute URI is returned by the script,
+ then the
+ server MUST generate a
+ '302 redirect' HTTP response
+ message unless the script has supplied an
+ explicit Status response header field.
+ Scripts returning an absolute URI MAY choose to
+ provide a message-body. Servers MUST make any appropriate modifications
+ to the script's output to ensure the response to the user-agent complies
+ with the response protocol version.
+ If the Location value is a path, then the server
+ MUST generate
+ the response that it would have produced in response to a request
+ containing the URL
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ scheme "://" SERVER_NAME ":" SERVER_PORT rel-URL-abs-path
+ </PRE>
+ <P>
+ Note: If the request was accompanied by a
+ message-body
+ (such as for a POST request), and the script
+ redirects the request with a Location field, the
+ message-body
+ may not be
+ available to the resource that is the target of the redirect.
+ </P>
+
+ <H4>
+ <A NAME="7.2.1.3">
+ 7.2.1.3. Status
+ </A>
+ </H4>
+ <P>
+ The "<SAMP>Status</SAMP>" header field is used to indicate to the server what
+ status code the server MUST use in the response message.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ Status = "Status" ":" digit digit digit SP reason-phrase NL
+ reason-phrase = *<CHAR, excluding CTLs, NL>
+ </PRE>
+ <P>
+ The valid status codes are listed in section 6.1.1 of the HTTP/1.0
+ specifications [<A HREF="#[3]">3</A>]. If the SERVER_PROTOCOL is
+ "HTTP/1.1", then the status codes defined in the HTTP/1.1
+ specification [<A HREF="#[8]">8</A>] may
+ be used. If the script does not return a "<SAMP>Status</SAMP>" header
+ field, then "200 OK" SHOULD be assumed by the server.
+ </P>
+ <P>
+ If a script is being used to handle a particular error or condition
+ encountered by the server, such as a '404 Not Found' error, the script
+ SHOULD use the "<SAMP>Status</SAMP>" CGI header field to propagate the error
+ condition back to the client. <EM>E.g.</EM>, in the example mentioned it
+ SHOULD include a "Status: 404 Not Found" in the
+ header data returned to the server.
+ </P>
+
+ <H4>
+ <A NAME="7.2.1.4">
+ 7.2.1.4. Extension header fields
+ </A>
+ </H4>
+ <P>
+ Scripts MAY include in their CGI response header additional fields
+ not defined in this or the HTTP specification.
+ These are called "extension" fields,
+ and have the syntax of a <SAMP>generic-field</SAMP> as defined in
+ <A HREF="#7.2.1">section 7.2.1</A>. The name of an extension field
+ MUST NOT conflict with a field name defined in this or any other
+ specification; extension field names SHOULD begin with "X-CGI-"
+ to ensure uniqueness.
+ </P>
+
+ <H4>
+ <A NAME="7.2.2">
+ 7.2.2. HTTP header fields
+ </A>
+ </H4>
+ <P>
+ The script MAY return any other header fields defined by the
+ specification
+ for the SERVER_PROTOCOL (HTTP/1.0 [<A HREF="#[3]">3</A>] or HTTP/1.1
+ [<A HREF="#[8]">8</A>]).
+ Servers MUST resolve conflicts beteen CGI header
+ and HTTP header formats or names (see <A HREF="#8.0">section 8</A>).
+ </P>
+
+ <H2>
+ <A NAME="8.0">
+ 8. Server Implementation
+ </A>
+ </H2>
+ <P>
+ This section defines the requirements that must be met by HTTP
+ servers in order to provide a coherent and correct CGI/1.1
+ environment in which scripts may function. It is intended
+ primarily for server implementors, but it is useful for
+ script authors to be familiar with the information as well.
+ </P>
+
+ <H3>
+ <A NAME="8.1">
+ 8.1. Requirements for Servers
+ </A>
+ </H3>
+ <P>
+ In order to be considered CGI/1.1-compliant, a server must meet
+ certain basic criteria and provide certain minimal functionality.
+ The details of these requirements are described in the following sections.
+ </P>
+
+ <H3>
+ <A NAME="8.1.1">
+ 8.1.1. Script-URI
+ </A>
+ </H3>
+ <P>
+ Servers MUST support the standard mechanism (described below) which
+ allows
+ script authors 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
+ metavariables. This
+ mechanism is as follows:
+ </P>
+ <P>
+ The server
+ MUST translate the header data from the CGI header field syntax to
+ the HTTP
+ header field 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 header fields returned by the script
+ and header fields that it would otherwise send itself.
+ </P>
+
+ <H3>
+ <A NAME="8.1.2">
+ 8.1.2. Request Message-body Handling
+ </A>
+ </H3>
+ <P>
+ These are the requirements for server handling of message-bodies directed
+ to CGI/1.1 resources:
+ </P>
+ <OL>
+ <LI>The message-body the server provides to the CGI script MUST
+ have any transfer encodings removed.
+ </LI>
+ <LI>The server MUST derive and provide a value for the CONTENT_LENGTH
+ metavariable that reflects the length of the message-body after any
+ transfer decoding.
+ </LI>
+ <LI>The server MUST leave intact any content-encodings of the message-body.
+ </LI>
+ </OL>
+
+ <H3>
+ <A NAME="8.1.3">
+ 8.1.3. Required Metavariables
+ </A>
+ </H3>
+ <P>
+ Servers MUST provide scripts with certain information and
+ metavariables
+ as described in <A HREF="#8.3">section 8.3</A>.
+ </P>
+
+ <H3>
+ <A NAME="8.1.4">
+ 8.1.4. Response Compliance
+ </A>
+ </H3>
+ <P>
+ Servers MUST ensure that responses sent to the user-agent meet all
+ requirements of the protocol level in effect. This may involve
+ modifying, deleting, or augmenting any header
+ fields and/or message-body supplied by the script.
+ </P>
+
+ <H3>
+ <A NAME="8.2">
+ 8.2. Recommendations for Servers
+ </A>
+ </H3>
+ <P>
+ Servers SHOULD provide the "<SAMP>query</SAMP>" component of the script-URI
+ as command-line arguments to scripts if it does not
+ contain any unencoded '=' characters and the command-line arguments can
+ be generated in an unambiguous manner.
+ (See <A HREF="#5.0">section 5</A>.)
+ </P>
+ <P>
+ Servers SHOULD set the AUTH_TYPE
+ metavariable to the value of the
+ '<SAMP>auth-scheme</SAMP>' token of the "<SAMP>Authorization</SAMP>"
+ field if it was supplied as part of the request header.
+ (See <A HREF="#6.1.1">section 6.1.1</A>.)
+ </P>
+ <P>
+ Where applicable, servers SHOULD set the current working directory
+ to the directory in which the script is located before invoking
+ it.
+ </P>
+ <P>
+ Servers MAY reject with error '404 Not Found'
+ any requests that would result in
+ an encoded "/" being decoded into PATH_INFO or SCRIPT_NAME, as this
+ might represent a loss of information to the script.
+ </P>
+ <P>
+ 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:
+ </P>
+ <OL>
+ <LI>define any restrictions on allowed characters, in particular
+ whether ASCII NUL is permitted;
+ </LI>
+ <LI>define any restrictions on allowed path segments, in particular
+ whether non-terminal NULL segments are permitted;
+ </LI>
+ <LI>define the behaviour for <SAMP>"."</SAMP> or <SAMP>".."</SAMP> path
+ segments; <EM>i.e.</EM>, whether they are prohibited, treated as
+ ordinary path
+ segments or interpreted in accordance with the relative URL
+ specification [<A HREF="#[7]">7</A>];
+ </LI>
+ <LI>define any limits of the implementation, including limits on path or
+ search string lengths, and limits on the volume of header data the server
+ will parse.
+ </LI><!-- ##### Move the field resolution/translation para below here -->
+ </OL>
+ <P>
+ Servers MAY generate the
+ Script-URI in
+ any way from the client URI,
+ or from any other data (but the behaviour SHOULD be documented).
+ </P>
+ <P>
+ For non-parsed header (NPH) scripts (see
+ <A HREF="#7.1">section 7.1</A>), servers SHOULD
+ attempt to ensure that the script input comes directly from the
+ client, with minimal buffering. For all scripts the data will be
+ as supplied by the client.
+ </P>
+
+ <H3>
+ <A NAME="8.3">
+ 8.3. Summary of
+ MetaVariables
+ </A>
+ </H3>
+ <P>
+ Servers MUST provide the following
+ metavariables to
+ scripts. See the individual descriptions for exceptions and semantics.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ CONTENT_LENGTH (section <A HREF="#6.1.2">6.1.2</A>)
+ CONTENT_TYPE (section <A HREF="#6.1.3">6.1.3</A>)
+ GATEWAY_INTERFACE (section <A HREF="#6.1.4">6.1.4</A>)
+ PATH_INFO (section <A HREF="#6.1.6">6.1.6</A>)
+ QUERY_STRING (section <A HREF="#6.1.8">6.1.8</A>)
+ REMOTE_ADDR (section <A HREF="#6.1.9">6.1.9</A>)
+ REQUEST_METHOD (section <A HREF="#6.1.13">6.1.13</A>)
+ SCRIPT_NAME (section <A HREF="#6.1.14">6.1.14</A>)
+ SERVER_NAME (section <A HREF="#6.1.15">6.1.15</A>)
+ SERVER_PORT (section <A HREF="#6.1.16">6.1.16</A>)
+ SERVER_PROTOCOL (section <A HREF="#6.1.17">6.1.17</A>)
+ SERVER_SOFTWARE (section <A HREF="#6.1.18">6.1.18</A>)
+ </PRE>
+ <P>
+ Servers SHOULD define the following
+ metavariables for scripts.
+ See the individual descriptions for exceptions and semantics.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ AUTH_TYPE (section <A HREF="#6.1.1">6.1.1</A>)
+ REMOTE_HOST (section <A HREF="#6.1.10">6.1.10</A>)
+ </PRE>
+ <P>
+ In addition, servers SHOULD provide
+ metavariables for all fields present
+ in the HTTP request header, with the exception of those involved with
+ access control. Servers MAY at their discretion provide
+ metavariables
+ for access control fields.
+ </P>
+ <P>
+ Servers MAY define the following
+ metavariables. See the individual
+ descriptions for exceptions and semantics.
+ </P><!--#if expr="! $GUI" -->
+ <P></P><!--#endif -->
+ <PRE>
+ PATH_TRANSLATED (section <A HREF="#6.1.7">6.1.7</A>)
+ REMOTE_IDENT (section <A HREF="#6.1.11">6.1.11</A>)
+ REMOTE_USER (section <A HREF="#6.1.12">6.1.12</A>)
+ </PRE>
+ <P>
+ Servers MAY
+ at their discretion define additional implementation-specific
+ extension metavariables
+ provided their names do not
+ conflict with defined header field names. Implementation-specific
+ metavariable names SHOULD
+ be prefixed with "X_" (<EM>e.g.</EM>,
+ "X_DBA") to avoid the potential for such conflicts.
+ </P>
+
+ <H2>
+ <A NAME="9.0">
+ 9.
+ Script Implementation
+ </A>
+ </H2>
+ <P>
+ This section defines the requirements and recommendations for scripts
+ that are intended to function in a CGI/1.1 environment. It is intended
+ primarily as a reference for script authors, but server implementors
+ should be familiar with these issues as well.
+ </P>
+
+ <H3>
+ <A NAME="9.1">
+ 9.1. Requirements for Scripts
+ </A>
+ </H3>
+ <P>
+ Scripts using the parsed-header method to communicate with servers
+ MUST supply a response header to the server.
+ (See <A HREF="#7.0">section 7</A>.)
+ </P>
+ <P>
+ Scripts using the NPH method to communicate with servers MUST
+ provide complete HTTP responses, and MUST use the value of the
+ SERVER_PROTOCOL metavariable
+ to determine the appropriate format.
+ (See <A HREF="#7.1">section 7.1</A>.)
+ </P>
+ <P>
+ Scripts MUST check the value of the REQUEST_METHOD
+ metavariable in order
+ to provide an appropriate response.
+ (See <A HREF="#6.1.13">section 6.1.13</A>.)
+ </P>
+ <P>
+ Scripts MUST be prepared to handled URL-encoded values in
+ metavariables.
+ In addition, they MUST recognise both "+" and "%20" in URL-encoded
+ quantities as representing the space character.
+ (See <A HREF="#3.1">section 3.1</A>.)
+ </P>
+ <P>
+ Scripts MUST ignore leading zeros in the major and minor version numbers
+ in the GATEWAY_INTERFACE
+ metavariable value. (See
+ <A HREF="#6.1.4">section 6.1.4</A>.)
+ </P>
+ <P>
+ When processing requests that include a
+ message-body, scripts
+ MUST NOT read more than CONTENT_LENGTH bytes from the input stream.
+ (See sections <A HREF="#6.1.2">6.1.2</A> and <A HREF="#6.2">6.2</A>.)
+ </P>
+
+ <H3>
+ <A NAME="9.2">
+ 9.2. Recommendations for Scripts
+ </A>
+ </H3>
+ <P>
+ Servers may interrupt or terminate script execution at any time
+ and without warning, so scripts SHOULD be prepared to deal with
+ abnormal termination.
+ </P>
+ <P>
+ Scripts MUST
+ reject with
+ error '405 Method Not
+ Allowed' requests
+ made using methods that they do not support. 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.
+ </P>
+ <P>
+ If a script is processing the output of a form, it SHOULD
+ verify that the CONTENT_TYPE
+ is "<SAMP>application/x-www-form-urlencoded</SAMP>" [<A HREF="#[2]">2</A>]
+ or whatever other media type is expected.
+ </P>
+ <P>
+ Scripts parsing PATH_INFO,
+ PATH_TRANSLATED, or SCRIPT_NAME
+ SHOULD be careful
+ of void path segments ("<SAMP>//</SAMP>") and special path segments
+ (<SAMP>"."</SAMP> and
+ <SAMP>".."</SAMP>). They SHOULD either be removed from the path before
+ use in OS
+ system calls, or the request SHOULD be rejected with
+ '404 Not Found'.
+ </P>
+ <P>
+ As it is impossible for
+ scripts to determine the client URI that
+ initiated a
+ request without knowledge of the specific server in
+ use, the script SHOULD NOT return "<SAMP>text/html</SAMP>"
+ documents containing
+ relative URL links without including a "<SAMP><BASE></SAMP>"
+ tag in the document.
+ </P>
+ <P>
+ When returning header fields,
+ scripts SHOULD try to send the CGI
+ header fields (see section
+ <A HREF="#7.2">7.2</A>) as soon as possible, and
+ SHOULD send them
+ before any HTTP header fields. This may
+ help reduce the server's memory requirements.
+ </P>
+
+ <H2>
+ <A NAME="10.0">
+ 10. System Specifications
+ </A>
+ </H2>
+
+ <H3>
+ <A NAME="10.1">
+ 10.1. AmigaDOS
+ </A>
+ </H3>
+ <P>
+ The implementation of the CGI on an AmigaDOS operating system platform
+ SHOULD use environment variables as the mechanism of providing
+ request metadata to CGI scripts.
+ </P>
+ <DL>
+ <DT><STRONG>Environment variables</STRONG>
+ </DT>
+ <DD>
+ <P>
+ These are accessed by the DOS library routine <SAMP>GetVar</SAMP>. The
+ flags argument SHOULD be 0. Case is ignored, but upper case is
+ recommended for compatibility with case-sensitive systems.
+ </P>
+ </DD>
+ <DT><STRONG>The current working directory</STRONG>
+ </DT>
+ <DD>
+ <P>
+ The current working directory for the script is set to the directory
+ containing the script.
+ </P>
+ </DD>
+ <DT><STRONG>Character set</STRONG>
+ </DT>
+ <DD>
+ <P>
+ The US-ASCII character set is used for the definition of environment
+ variable names and header
+ field names; the newline (NL) sequence is LF;
+ servers SHOULD also accept CR LF as a newline.
+ </P>
+ </DD>
+ </DL>
+
+ <H3>
+ <A NAME="10.2">
+ 10.2. Unix
+ </A>
+ </H3>
+ <P>
+ The implementation of the CGI on a UNIX operating system platform
+ SHOULD use environment variables as the mechanism of providing
+ request metadata to CGI scripts.
+ </P>
+ <P>
+ For Unix compatible operating systems, the following are defined:
+ </P>
+ <DL>
+ <DT><STRONG>Environment variables</STRONG>
+ </DT>
+ <DD>
+ <P>
+ These are accessed by the C library routine <SAMP>getenv</SAMP>.
+ </P>
+ </DD>
+ <DT><STRONG>The command line</STRONG>
+ </DT>
+ <DD>
+ <P>
+ This is accessed using the
+ <SAMP>argc</SAMP> and <SAMP>argv</SAMP>
+ arguments to <SAMP>main()</SAMP>. The words have any characters
+ that
+ are 'active' in the Bourne shell escaped with a backslash.
+ If the value of the QUERY_STRING
+ metavariable
+ contains an unencoded equals-sign '=', then the command line
+ SHOULD NOT be used by the script.
+ </P>
+ </DD>
+ <DT><STRONG>The current working directory</STRONG>
+ </DT>
+ <DD>
+ <P>
+ The current working directory for the script
+ SHOULD be set to the directory
+ containing the script.
+ </P>
+ </DD>
+ <DT><STRONG>Character set</STRONG>
+ </DT>
+ <DD>
+ <P>
+ The US-ASCII character set is used for the definition of environment
+ variable names and header field names; the newline (NL) sequence is LF;
+ servers SHOULD also accept CR LF as a newline.
+ </P>
+ </DD>
+ </DL>
+
+ <H2>
+ <A NAME="11.0">
+ 11. Security Considerations
+ </A>
+ </H2>
+
+ <H3>
+ <A NAME="11.1">
+ 11.1. Safe Methods
+ </A>
+ </H3>
+ <P>
+ As discussed in the security considerations of the HTTP
+ specifications [<A HREF="#[3]">3</A>,<A HREF="#[8]">8</A>], the
+ convention has been established that the
+ GET and HEAD methods should be 'safe'; they should cause no
+ side-effects and only have the significance of resource retrieval.
+ </P>
+ <P>
+ CGI scripts are responsible for enforcing any HTTP security considerations
+ [<A HREF="#[3]">3</A>,<A HREF="#[8]">8</A>]
+ with respect to the protocol version level of the request and
+ any side effects generated by the scripts on behalf of
+ the server. Primary
+ among these
+ are the considerations of safe and idempotent methods. Idempotent
+ requests are those that may be repeated an arbitrary number of times
+ and produce side effects identical to a single request.
+ </P>
+
+ <H3>
+ <A NAME="11.2">
+ 11.2. HTTP Header
+ Fields Containing Sensitive Information
+ </A>
+ </H3>
+ <P>
+ Some HTTP header fields may carry sensitive information which the server
+ SHOULD NOT pass on to the script unless explicitly configured to do
+ so. For example, if the server protects the script using the
+ "<SAMP>Basic</SAMP>"
+ authentication scheme, then the client will send an
+ "<SAMP>Authorization</SAMP>"
+ header field containing a username and password. If the server, rather
+ than the script, validates this information then the password SHOULD
+ NOT be passed on to the script <EM>via</EM> the HTTP_AUTHORIZATION
+ metavariable
+ without careful consideration.
+ This also applies to the
+ Proxy-Authorization header field and the corresponding
+ HTTP_PROXY_AUTHORIZATION
+ metavariable.
+ </P>
+
+ <H3>
+ <A NAME="11.3">
+ 11.3. Script
+ Interference with the Server
+ </A>
+ </H3>
+ <P>
+ The most common implementation of CGI invokes the script as a child
+ process using the same user and group as the server process. It
+ SHOULD therefore be ensured that the script cannot interfere with the
+ server process, its configuration, or documents.
+ </P>
+ <P>
+ If the script is executed by calling a function linked in to the
+ server software (either at compile-time or run-time) then precautions
+ SHOULD be taken to protect the core memory of the server, or to
+ ensure that untrusted code cannot be executed.
+ </P>
+
+ <H3>
+ <A NAME="11.4">
+ 11.4. Data Length and Buffering Considerations
+ </A>
+ </H3>
+ <P>
+ This specification places no limits on the length of message-bodies
+ presented to the script. Scripts should not assume that statically
+ allocated buffers of any size are sufficient to contain the entire
+ submission at one time. Use of a fixed length buffer without careful
+ overflow checking may result in an attacker exploiting 'stack-smashing'
+ or 'stack-overflow' vulnerabilities of the operating system.
+ Scripts may spool large submissions to disk or other buffering media,
+ but a rapid succession of large submissions may result in denial of
+ service conditions. If the CONTENT_LENGTH of a message-body is larger
+ than resource considerations allow, scripts should respond with an
+ error status appropriate for the protocol version; potentially applicable
+ status codes include '503 Service Unavailable' (HTTP/1.0 and HTTP/1.1),
+ '413 Request Entity Too Large' (HTTP/1.1), and
+ '414 Request-URI Too Long' (HTTP/1.1).
+ </P>
+
+ <H3>
+ <A NAME="11.5">
+ 11.5. Stateless Processing
+ </A>
+ </H3>
+ <P>
+ The stateless nature of the Web makes each script execution and resource
+ retrieval independent of all others even when multiple requests constitute a
+ single conceptual Web transaction. Because of this, a script should not
+ make any assumptions about the context of the user-agent submitting a
+ request. In particular, scripts should examine data obtained from the client
+ and verify that they are valid, both in form and content, before allowing
+ them to be used for sensitive purposes such as input to other
+ applications, commands, or operating system services. These uses
+ include, but are not
+ limited to: system call arguments, database writes, dynamically evaluated
+ source code, and input to billing or other secure processes. It is important
+ that applications be protected from invalid input regardless of whether
+ the invalidity is the result of user error, logic error, or malicious action.
+ </P>
+ <P>
+ Authors of scripts involved in multi-request transactions should be
+ particularly cautios about validating the state information;
+ undesirable effects may result from the substitution of dangerous
+ values for portions of the submission which might otherwise be
+ presumed safe. Subversion of this type occurs when alterations
+ are made to data from a prior stage of the transaction that were
+ not meant to be controlled by the client (<EM>e.g.</EM>, hidden
+ HTML form elements, cookies, embedded URLs, <EM>etc.</EM>).
+ </P>
+
+ <H2>
+ <A NAME="12.0">
+ 12. Acknowledgements
+ </A>
+ </H2>
+ <P>
+ This work is based on a draft published in 1997 by David R. Robinson,
+ which in turn was based on the original CGI interface that arose out of
+ discussions on the <EM>www-talk</EM> mailing list. In particular,
+ Rob McCool, John Franks, Ari Luotonen,
+ George Phillips and
+ Tony Sanders deserve special recognition for their efforts in
+ defining and implementing the early versions of this interface.
+ </P>
+ <P>
+ This document has also greatly benefited from the comments and
+ suggestions made by Chris Adie, Dave Kristol,
+ Mike Meyer, David Morris, Jeremy Madea,
+ Patrick M<SUP>c</SUP>Manus, Adam Donahue,
+ Ross Patterson, and Harald Alvestrand.
+ </P>
+
+ <H2>
+ <A NAME="13.0">
+ 13. References
+ </A>
+ </H2>
+ <DL COMPACT>
+ <DT><A NAME="[1]">[1]</A>
+ </DT>
+ <DD>Berners-Lee, T., 'Universal Resource Identifiers in WWW: A
+ Unifying Syntax for the Expression of Names and Addresses of
+ Objects on the Network as used in the World-Wide Web', RFC 1630,
+ CERN, June 1994.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[2]">[2]</A>
+ </DT>
+ <DD>Berners-Lee, T. and Connolly, D., 'Hypertext Markup Language -
+ 2.0', RFC 1866, MIT/W3C, November 1995.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[3]">[3]</A>
+ </DT>
+ <DD>Berners-Lee, T., Fielding, R. T. and Frystyk, H.,
+ 'Hypertext Transfer Protocol -- HTTP/1.0', RFC 1945, MIT/LCS,
+ UC Irvine, May 1996.
+ <P>
+ </P>
+ </DD>
+
+ <DT><A NAME="[4]">[4]</A>
+ </DT>
+ <DD>Berners-Lee, T., Fielding, R., and Masinter, L., Editors,
+ 'Uniform Resource Identifiers (URI): Generic Syntax', RFC 2396,
+ MIT, U.C. Irvine, Xerox Corporation, August 1996.
+ <P>
+ </P>
+ </DD>
+
+ <DT><A NAME="[5]">[5]</A>
+ </DT>
+ <DD>Braden, R., Editor, 'Requirements for Internet Hosts --
+ Application and Support', STD 3, RFC 1123, IETF, October 1989.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[6]">[6]</A>
+ </DT>
+ <DD>Crocker, D.H., 'Standard for the Format of ARPA Internet Text
+ Messages', STD 11, RFC 822, University of Delaware, August 1982.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[7]">[7]</A>
+ </DT>
+ <DD>Fielding, R., 'Relative Uniform Resource Locators', RFC 1808,
+ UC Irvine, June 1995.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[8]">[8]</A>
+ </DT>
+ <DD>Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
+ Berners-Lee, T., 'Hypertext Transfer Protocol -- HTTP/1.1',
+ RFC 2068, UC Irvine, DEC,
+ MIT/LCS, January 1997.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[9]">[9]</A>
+ </DT>
+ <DD>Freed, N. and Borenstein N., 'Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types', RFC 2046, Innosoft,
+ First Virtual, November 1996.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[10]">[10]</A>
+ </DT>
+ <DD>Mockapetris, P., 'Domain Names - Concepts and Facilities',
+ STD 13, RFC 1034, ISI, November 1987.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[11]">[11]</A>
+ </DT>
+ <DD>St. Johns, M., 'Identification Protocol', RFC 1431, US
+ Department of Defense, February 1993.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[12]">[12]</A>
+ </DT>
+ <DD>'Coded Character Set -- 7-bit American Standard Code for
+ Information Interchange', ANSI X3.4-1986.
+ <P>
+ </P>
+ </DD>
+ <DT><A NAME="[13]">[13]</A>
+ </DT>
+ <DD>Hinden, R. and Deering, S.,
+ 'IP Version 6 Addressing Architecture', RFC 2373,
+ Nokia, Cisco Systems,
+ July 1998.
+ <P>
+ </P>
+ </DD>
+ </DL>
+
+ <H2>
+ <A NAME="14.0">
+ 14. Authors' Addresses
+ </A>
+ </H2>
+ <ADDRESS>
+ <P>
+ Ken A L Coar
+ <BR>
+ MeepZor Consulting
+ <BR>
+ 7824 Mayfaire Crest Lane, Suite 202
+ <BR>
+ Raleigh, NC 27615-4875
+ <BR>
+ U.S.A.
+ </P>
+ <P>
+ Tel: +1 (919) 254.4237
+ <BR>
+ Fax: +1 (919) 254.5250
+ <BR>
+ Email:
+ <A
+ HREF="mailto:Ken.Coar@Golux.Com"
+ ><SAMP>Ken.Coar@Golux.Com</SAMP></A>
+ </P>
+ </ADDRESS>
+ <ADDRESS>
+ <P>
+ David Robinson
+ <BR>
+ E*TRADE UK Ltd
+ <BR>
+ Mount Pleasant House
+ <BR>
+ 2 Mount Pleasant
+ <BR>
+ Huntingdon Road
+ <BR>
+ Cambridge CB3 0RN
+ <BR>
+ UK
+ </P>
+ <P>
+ Tel: +44 (1223) 566926
+ <BR>
+ Fax: +44 (1223) 506288
+ <BR>
+ Email:
+ <A
+ HREF="mailto:drtr@etrade.co.uk"
+ ><SAMP>drtr@etrade.co.uk</SAMP></A>
+ </ADDRESS>
+
+ </BODY>
+</HTML>
projects / platform / upstream / busybox.git / commitdiff