RFC 3875 CGI Version 1.1 October 2004
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
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  and RFC 2732 . 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.
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
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 , , and also the IANA HTTP Status Code Registry
 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
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  or HTTP/1.1 ). 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