| <!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> |