Chapter 3: Understanding HTTP

Response status messages


[ Comments ] [ Copyright ] [ Chapter contents ] [ Book contents ]


From time to time, you will click a link and see, not a pretty document or image, but a bald, bare, error message, usually with a number attached.

In point of fact, every time you send an HTTP request, the web server returns a MIME header. The first line of the response consists of:

HTTP-Version<SP>Status-Code<SP>Reason-Phrase<CR><LF>

for example:

HTTP/1.0 200 OK

This is the standard response to a successful GET request for an HTML document. It would normally be followed by more header information, such as the Content-type, the Content-length, and then the MIME-encapsulated document.

However, there are some other possible responses:
Created 201Following a POST command, this indicates that a document was successfully created. The textual part of the response line indicates the URI by which the newly created document is known.
Accepted 202The request has been accepted for processing, but processing has not been completed. (In other words, the request is being executed asynchronously.) The request may or may not eventually be acted upon; there is no facility for status reports on asynchronous operations.
No Response 204The server has received the request but there is no information to send back, and the browser should stay in the same document view. This is mainly to allow input for scripts to be received without the browser changing the document at the same time.
Redirection: 300The target URI has moved. (See below).
Error 4xx, 5xxThe 4xx codes indicate that the browser seems to have made a mistake, and the 5xx codes indicate that the server is aware that it has encountered an internal error. It is often impossible to distinguish these cases. The body section may contain a document describing the error in human readable form.

The commonest error messages are:
Bad request 400The request was badly formed or impossible to satisfy.
Unauthorized 401Returned by a server where access control (typically through HTACCESS) is in force. The parameter to this message specifies a set of authorization schemes which are acceptable. The browser should retry the request with a suitable Authorization: header.
PaymentRequired 402The parameter to this message specifies acceptable charging schemes. The client may retry the request with a suitable ChargeTo: header. (This is not in general use yet.)
Forbidden 403The request is forbidden. Authorization will not help.
Not found 404The server has not found anything matching the URI given
Internal Error 500The server encountered an unexpected condition which prevented it from fulfilling the request. Typical causes of this message include a CGI script failure, or corrupt output from a script.
Not implemented 501The server does not support the facility required.
Service temporarily overloaded 502The server cannot process the request due to a high load (whether servicing HTTP or other requests). The implication is that this is a temporary condition.
Gateway timeout 503 This is equivalent to Internal Error 500, but indicates that rather than the server being at fault, the fault lies in some other service that the server was invoking to fulfil the request; the respose from the other service did not arrive within the time that the gateway was prepared to wait. As from the point of view of the client the HTTP transaction to the other service is hidden within the server, this may be treated identically to Internal error 500, but has more diagnostic value.

Redirection codes (3xx) indicate that the request can't be handled by the server, but is not necessarily invalid; some action can be taken by the browser to fulfil the request. These codes are:
Moved 301The data requested has been assigned a new URI. The change is permanent. (Browsers with link editing capabiliy should automatically relink to the new reference). The response contains one or more header lines which specify alternative addresses for the object in question.
Found 302The data requested actually resides under a different URL, however the redirection may be altered on occasion.

In general, HTTP return codes are not displayed by a browser unless something has gone wrong. They can be invaluable in debugging a web, though. For example, the commonest error returned by a malfunctioning CGI script is 500: Malformed header from script. This means that the CGI script either failed to run, or returned something that wasn't a valid MIME-encapsulated response to the server, and is the cue to the programmer to check the server error_log file (for whatever error output the script produced).


[ Comments ] [ Copyright ] [ Chapter contents ] [ Book contents ]