Home
 Products
 Download
 Buy
 Support
- F.A.Q.
- Error Codes
-- Winsock Errors
-- HTTP 1.0 Errors
-- HTTP 1.1 Errors

- Configuration
- Release Notes
- Year 2000

 Beta Area
 Contacts
 About Us




Server Status Code Definitions

From HTTP/1.1 - RFC2068
When you follow a link, or type in a web address, your local ISP sends that request to the appropriate server - usually the "www.company.com" part of the original address.

That server then tries to deliver the requested page to you.

The server also registers whether or not it has been able to deliver that request successfully, and generates a "Status Code".

Mostly, these messages are unseen by the user - especially when the request is successful. On other occasions, they may point to the reasons for any problem in displaying the requested page. These are the 400 and 500 series codes.
1xx
Informational
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
100
Continue
The client may continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.
101
Switching Protocols
The server understands and is willing to comply with the client's request, via the Upgrade message header field, for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response. The protocol should only be switched when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol may be advantageous when delivering resources that use such features.
2xx
Successful
This class of status code indicates that the client's request was successfully received, understood, and accepted.
200
OK
The request has succeeded.

The server also sends extra information to your browser dependent on the method used in the request, as follows:
  • GET - an entity (a "page") corresponding to the requested resource is sent
  • HEAD - the server sends the page header, and nothing else (your browser uses this to decide whether the copy in your cache needs updating
  • POST - an entity (a "page") describing or containing the result of the action.
  • TRACE an entity containing the request message as received by the end server.
201
Created
A new resource (a "page") has been created, and your browser should display the address of this page.
202
Accepted
This tells your browser that your request has been accepted, but not yet completed (this is usually some background process).
203
Non-Authoritative Information
The requested page may contain material from other sources, which may be more up to date. For all practical purposes, this means the same as 200.
204
No Content
The server has fulfilled the request but there is no new information to send back. You will see no change in your browser.
205
Reset Content
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action.
206
Partial Content
This code is passed to your browser to tell it that some of its request has been fulfilled. The rest is (probably) on its way.
3xx
Redirection
This class of status code indicates that further action needs to be taken by the user agent (your browser) in order to fulfill the request.
300
Multiple Choices
This response code is not directly used by HTTP/1.0 applications, but serves as the default for interpreting the 3xx class of responses.

It means that the requested resource is available at one or more locations. If the server has a preferred choice, it should include the URL in a Location field; user agents (browsers) may use this field value for automatic redirection.
301
Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD be done using one of the returned URIs. Clients (browsers) with link editing capabilities SHOULD automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cachable unless indicated otherwise. If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
302
Moved Temporarily
The requested resource resides temporarily under a different URI. Since the redirection may be altered on occasion, the client (the browser) SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field.

If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
303
See Other
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response is not cachable, but the response to the second (redirected) request MAY be cachable.

If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
304
Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The response MUST NOT contain a message-body.

The response MUST include the following header fields:
  • Date
  • ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
  • Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
If the conditional GET used a strong cache validator (see section, the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional. If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. The 304 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
305
Use Proxy
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URL of the proxy. The recipient is expected to repeat the request via the proxy.
4xx
Client Error
The 4xx class of status code is intended for cases in which the client seems to have erred. More simply, it means that the server can't find the address you've given it.

Servers will send your browser a page with the status code number on it (but little more
explanation).
400
Bad Request
The request could not be understood by the server due to malformed syntax - perhaps because you've typed an illegal character, or put in too many slashes (///).
401
Unauthorized
The request requires user authentication (which hasn't been supplied, or which is incorrect).
402
Payment Required
This code is reserved for future use.
403
Forbidden
The server understood the request, but is refusing to fulfill it.

This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
404
Not Found
The server has not found anything matching the Request-URI (the "address"). This may mean that you have typed a wrong address, or the page which once was there has now been removed.
405
Method Not Allowed
The method specified in the Request-Line is not allowed (by the server) for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
406
Not Acceptable
The server can't supply what your browser asked for, in a form that your browser can use.
407
Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy being used for this connection.
408
Request Timeout
The client (you, or your browser) did not produce a request within the time that the server was prepared to wait. You can try again later.
409
Conflict
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that may not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request (uploading material to a web-site). If version control is being used and the material breaks the rules, the server MAY use the 409 response to indicate that it can't complete the request. In this case, the response entity SHOULD contain a list of the differences between the two versions.
410
Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition SHOULD be considered permanent.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
411
Length Required
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
412
Precondition Failed
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows your browser (perhaps using a form) to exclude certain material.
413
Request Entity Too Large
The server is refusing to process a request because the material is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time you may try again.
414
Request-URI Too Long
The server is refusing to service the request because the Request-URI (the address) is longer than the server is willing to interpret. Rare.
415
Unsupported Media Type
The server is refusing to service the request because the material is in a format which can't be delivered in the form requested.
5xx
Server Error
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. If you see one of these, there is nothing you can do about it, but try again later (or contact the webmaster).
500
Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.
501
Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it.
502
Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
503
Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition.

Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
504
Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server it accessed in attempting to complete the request.
505
HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client. The response SHOULD contain an explanation.