Status

sets the status of the HTTP response.

Syntax

Response.Status = cHttpStatusCode | nHttpStatusCode

Note

Component of any HTTP response is a status code indicating errors that occurred in the processing of the request. The different error codes let the user determine which error has occurred. These error codes are standardized; they are made up of three-digit numbers. The following table lists the key error codes:

Code	Name	Description
200	OK	The page requested was processed without problems. The document or the data provided by the document are returned in the response. In virtually all cases this status code will be the correct value. For this reason it is also the default value for all AFP pages that were processed without error.
204	No Content	The request does not return data but was processed successfully. Browsers react to this by continuing to display the preceding page. This response code is useful whenever a page executes only one action. Typical examples of this would be saving data in a form or sending an e-mail.
301	Moved Permanently	Originally, this status code served the purpose of indicating changes in a web server's file structure. The web server was to send a location header along with this status code indicating the new address of the page requested. The browser can then request this page and display it to the user; the decision rests entirely with the browser rather than with the server.
302	Moved Temporarily	Similarly to code 301 the browser will be referred to an alternative page. In practice, status code 302 is mainly used for re-routing to alternative pages, since this alteration should not be permanently stored in the browser page. As a rule this is done without regard to whether or not the page has actually been moved. In essence, the task of method Response.Redirect() includes the generation of a response with the status code 302.
304	Not Modified	Whenever there is a file in the local cache of the browser, it transmits the date of its own file along with the request to the server. The server will then check whether the file on the server has changed since then. If this is not the case, response 304 can be returned. This will not be a frequent occurrence with AFP pages as the declared purpose of AFP pages is the provision of dynamic content. By contrast this response will frequently be returned for files that are managed by the web server itself, primarily for image files used within a web page.
401	Unauthorized	User names and passwords can be submitted in any web request. If access to a page is not protected, this data will be ignored. In the case of a protected page, however, this response can be transmitted if the password is missing or wrong. Most browsers will prompt the user to enter username and password in a dialogue and will then call the page again with the newly entered data.
403	Forbidden	Access to the requested document was denied. The web server sends this message whenever access is not allowed on principle or whenever the passwords transmitted in the request do not entitle the user to access. In this case the web application first responded with error code 401. The user was prompted by the browser to enter his username and his password. If these are correct, the web application will transmit the document with status code 200, else an error with status code 403.
404	Not Found	The page requested does not exist. This usually indicates a typing error during data entry on the user pages or a defective link in one of the web applications. Through configuration of the ISAPI extension IIS you can test whether the requested page actually exists. ISS will return error 404 if this option is selected and the page does not exist in the directory managed by IIS. AFP will trigger this error if the file exists neither in the web server's directory nor in the directory specified through the <virtual> tree in afp.config. AFP documents will generally return this error only in generic documents such as those returning PDF files.
500	Internal Server Error	Since an irreparable error occurred during processing, the requested document could not be returned. AFP will generate this message every time processing could not be started for a variety of reasons like a faulty AFP configuration. Error code 500 will also be returned whenever an error occurred during the page processing. This may be an error during compilation, a syntax error in the code, or an error during program execution that will cause VFP to call up the error handling routine.

There are additional messages aside from the codes listed above but their occurrence is infrequent. These status codes are split in the following five groups:

Code	Description
1xx	Purely informational
2xx	Successful requests
3xx	Requests will be re-routed
4xx	Faulty requests
5xx	Server errors

Starting with v. 4.0, Microsoft's IIS returns extended error codes in addition to these standardized error codes. These extended codes are attached to the original code number, separated by a dot. Thus, error "403.4" would indicate that SSL is required, or "403.6" would mean that the client's IP address lacks access privileges. In both cases, however, this would be error "403", "Access denied".

In the following example an HTTP error 404 is returned if the data record cannot be found:

IF NOT SEEK(lcID)

Response.Clear()

Response.Status = "404 record not found"

ENDIF

You may either set the status numerically through one of the codes or you can specify a character string with descriptive text. In that case the error code must be placed at the front of the character string. Most clients will ignore error text.

You should bear in mind that this is a status code, not an error code. All returns hitherto processed by the page will always be transmitted as responses even if the error code indicates that no data will be provided. In cases like these you can delete previous returns through Response.Clear().

What exactly happens when you send an error code like 404 or 500 depends on the web server and the browser employed. Most browsers will display pages returned by the browser without informing the user that there has been an error. That is why the page you send in cases of error should make this unequivocally clear.

Most web servers will return the page they received from AFP even if an error code was transmitted. While this on one hand allows you to create error pages at your discretion, it also means that you have no access to the error pages configured in the web server.