List of HTTP Response Codes
| Ever tried to analyse those annoying Server Erros when you try to access a particular Webpage?If not,let me do this for you.So,we're going to start from scratch.
There are a series of response codes to indicate the status of request.They are classified into 5 classes as: 1. 100 series - Informational 2. 200 series - Success 3. 300 series - Redirection 4. 400 series - Client Error 5. 500 series - Server Error So,now that we know the series lets dig furthur into these: 1.100 series - Informational • 100 - Continue This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request and check if a 100 Continue status code is received in response before continuing. • 101 - Switching Protocols This means the requester has asked the server to switch protocols and the server is acknowledging that it will do so. • 102 - Processing The 102 status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 response. The server MUST send a final response after the request has been completed. • 103 - Access Denied while creating Web Service Meaning is installation/implementation dependent. • 104 - File Format or Program Error The program running has an internal format or logic error. For example, comment lines incorrectly delineated,or the format of a Server Log of configuration file has become corrupted. 2.200 series - Success • 200 - OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: GET an entity corresponding to the requested resource is sent in the response; HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body; POST an entity describing or containing the result of the action; TRACE an entity containing the request message as received by the end server. • 201 - Created The request has been fulfilled and resulted in a new resource being created. • 202 - Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. • 203 - Non-Authoritative Information The server successfully processed the request, but is returning information that may be from another source. • 204 - No Content The server successfully processed the request, but is not returning any content. • 205 - Reset Content The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view. • 206 - Partial Content The server is delivering only part of the resource due to a range header sent by the client. This is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams. • 207 - Multi-Status Response The default 207 response body is a text/xml or application/xml HTTP entity that contains a single XML element called multi-status, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a response XML element. • 226 - IM Used The IM response-header field is used to indicate the instance-manipulations, if any, that have been applied to the instance represented by the response. Typical instance manipulations include delta encoding and compression. Responses that include an IM header MUST carry a response status code of 226. 3.300 series - Redirection • 300 - Multiple Choices Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation. • 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 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 cacheable 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 SHOULD continue to use the Request-URI for future requests. This response is only cacheable 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 another URI using a GET method. When received in response to a PUT, it should be assumed that the server has received the data and the redirect should be issued with a separate GET message. • 304 - Not Modified Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Utilizing this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then resent using more bandwidth of the server and client. • 305 - Use Proxy Many HTTP clients (such as Mozilla[4] and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons. Thus, 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. • 306 - Switch Proxy The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved. • 307 - Temporarily Redirected In this occasion, the request should be repeated with another URI, but future requests can still use the original URI. In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request. 4.400 series - Client Error • 400 - Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. • 401 - Unauthorized Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The server must also return a Proxy-Authenticate header along with this status code. • 402 - Payment Required The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code has never been used. • 403 - Forbidden The request was a legal request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference. • 404 - Not Found The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible. • 405 - Method Not Allowed A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource. • 406 - Not Acceptable The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request. • 407 - Proxy Authentification Required This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field. • 408 - Request Timeout The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. • 409 - Conflict Indicates that the request could not be processed because of conflict in the request, such as an edit conflict. • 410 - Gone Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed; however, it is not necessary to return this code and a 404 Not Found can be issued instead. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indexes. • 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 the client to place preconditions on the current resource meta-information (header field data) and thus prevent the requested method from being applied to a resource other than the one intended. • 413 - Request Entity Too Large The server is refusing to process a request because the request entity 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 the client may try again. • 414 - Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URL "black hole" of redirection (e.g., a redirected URL prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI. • 415 - Unsupported Media Type The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. • 416 - Request Range Not Satisfiable The client has asked for a portion of the file, but the server cannot supply that portion (for example, if the client asked for a part of the file that lies beyond the end of the file). • 417 - Expectation Failed The expectation given in an Expect request-header field could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server. • 418 - I'm a Teapot Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. As defined by IETF memo RFC 2324,.this memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Of British origin, clearly. • 419 - Expectation Failed The expectation given in an "Expect" request-header field could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server. • 420 - Policy not Fullfilled The policy for accessing the resource has not been met in the request. The response MUST include a PEP-Info or a C-PEP-Info header field specifying the extensions required by the publishing party for accessing the resource. The server MAY use the for attribute bag to indicate whether the policy applies to other resources. The client MAY repeat the request using the appropriate extensions). If the initial request already included the extensions requested in the 420 response, then the response indicates that access has been refused for those extension declarations. If the 420 response contains the same set of extension policies as the prior response, then the client MAY present any entity included in the response to the user, since that entity may include relevant diagnostic information. Implementers may note the similarity to the way authentication challenges are issued with the 401 (Unauthorized) status-code. • 421 - Bad Mapping The mappings indicated by one or more map attribute bags in the request were not unique and mapped the same header field more than once. The client MAY repeat the request using a new set of mappings if it believes that it can find a unique set of header fields for which the transaction will succeed. • 422 - Unprocessable Entity The request was well-formed but was unable to be followed due to semantic errors. • 423 - Entity Locked The resource that is being accessed is locked. • 424 - Failed Dependency The 424 status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424. • 425 - Unordered Collection Defined in drafts of WebDav Advanced Collections, but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol". • 426 - Update Required The Upgrade response header field advertises possible protocol upgrades a server MAY accept. In conjunction with the "426 Upgrade Required" status code, a server can advertise the exact protocol upgrades that a client MUST accept to complete the request. The server MAY include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of the protocols listed 5.500 series - Server Error • 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 for any resource. • 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 unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state. • 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. •&nsbp;505 - HTTP Version Not Supported The server does not support the HTTP protocol version used in the request. • 506 - Variant Also Negotiates,Not An Endpoint The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process. • 507 - Insufficient Storage The 507 status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action. • 508 - Cross Server Binding Forbidden Since most servers will be forced to fail cross-server BIND requests because they are unable to guarantee the integrity of cross-server bindings, status code 508 is defined. • 509 - Bandwidth Limit Exceeded Implementation dependent. The bandwidth available with your ISP or circuit provider has been/or soon will be exceeded. Different thresholds are used. 80 - 90% is common. • 510 - Request Not Extended The server must identify all mandatory extension declarations (both hop-by-hop and end-to-end); the server MAY ignore optional declarations without affecting the result of processing the HTTP message, and examine all extensions identified to determine if they are supported for this message. If not, respond with a 510 999 - Unknown or Indeterminate Added by CCS to indicate that available logic and information does not permit isolating the error completely. No additional information is available. Try the page request again. Check Browser, Computer, Server and Communication Software and Equipment conditions. Hope this was informative,please post your feedback! |