RFC 3875                    CGI Version 1.1                 October 2004


6.3.2.  Location

   The Location header field is used to specify to the server that the
   script is returning a reference to a document rather than an actual
   document (see sections 6.2.3 and 6.2.4).  It is either an absolute
   URI (optionally with a fragment identifier), indicating that the
   client is to fetch the referenced document, or a local URI path
   (optionally with a query string), indicating that the server is to
   fetch the referenced document and return it to the client as the
   response.

      Location        = local-Location | client-Location
      client-Location = "Location:" fragment-URI NL
      local-Location  = "Location:" local-pathquery NL
      fragment-URI    = absoluteURI [ "#" fragment ]
      fragment        = *uric
      local-pathquery = abs-path [ "?" query-string ]
      abs-path        = "/" path-segments
      path-segments   = segment *( "/" segment )
      segment         = *pchar
      pchar           = unreserved | escaped | extra
      extra           = ":" | "@" | "&" | "=" | "+" | "$" | ","

   The syntax of an absoluteURI is incorporated into this document from
   that specified in RFC 2396 [2] and RFC 2732 [7].  A valid absoluteURI
   always starts with the name of scheme followed by ":"; scheme names
   start with a letter and continue with alphanumerics, "+", "-" or ".".
   The local URI path and query must be an absolute path, and not a
   relative path or NULL, and hence must start with a "/".

   Note that any message-body attached to the request (such as for a
   POST request) may not be available to the resource that is the target
   of the redirect.

6.3.3.  Status

   The Status header field contains a 3-digit integer result code that
   indicates the level of success of the script's attempt to handle the
   request.

      Status         = "Status:" status-code SP reason-phrase NL
      status-code    = "200" | "302" | "400" | "501" | extension-code
      extension-code = 3digit
      reason-phrase  = *TEXT

   Status code 200 'OK' indicates success, and is the default value
   assumed for a document response.  Status code 302 'Found' is used
   with a Location header field and response message-body.  Status code




 
RFC 3875                    CGI Version 1.1                 October 2004


   400 'Bad Request' may be used for an unknown request format, such as
   a missing CONTENT_TYPE.  Status code 501 'Not Implemented' may be
   returned by a script if it receives an unsupported REQUEST_METHOD.

   Other valid status codes are listed in section 6.1.1 of the HTTP
   specifications [1], [4], and also the IANA HTTP Status Code Registry
   [8] and MAY be used in addition to or instead of the ones listed
   above.  The script SHOULD check the value of SERVER_PROTOCOL before
   using HTTP/1.1 status codes.  The script MAY reject with error 405
   'Method Not Allowed' HTTP/1.1 requests made using a method it does
   not support.

   Note that returning an error status code does not have to mean an
   error condition with the script itself.  For example, a script that
   is invoked as an error handler by the server should return the code
   appropriate to the server's error condition.

   The reason-phrase is a textual description of the error to be
   returned to the client for human consumption.

6.3.4.  Protocol-Specific Header Fields

   The script MAY return any other header fields that relate to the
   response message defined by the specification for the SERVER_PROTOCOL
   (HTTP/1.0 [1] or HTTP/1.1 [4]).  The server MUST translate the header
   data from the CGI header syntax to the HTTP header syntax if these
   differ.  For example, the character sequence for newline (such as
   UNIX's US-ASCII LF) used by CGI scripts may not be the same as that
   used by HTTP (US-ASCII CR followed by LF).

   The script MUST NOT return any header fields that relate to
   client-side communication issues and could affect the server's
   ability to send the response to the client.  The server MAY remove
   any such header fields returned by the client.  It SHOULD resolve any
   conflicts between header fields returned by the script and header
   fields that it would otherwise send itself.

6.3.5.  Extension Header Fields