| Class | HTTP Code |
Server Response |
Description |
|---|---|---|---|
| Successful | 200 | Ok | The request has been fulfilled and an entity corresponding to the requested resource is being sent in the response. If the HEAD method was used, the response should only contain the Entity-Header information and no Entity-Body. |
| 201 | Created | The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the URI-header field of the response. The origin server is encouraged, but not obliged, to actually create the resource before using this Status-Code. If the action cannot be carried out immediately, or within a clearly defined timeframe, the server should respond with "202 Accepted" instead. Of the methods defined by this specification, only PUT and POST can create a resource. | |
| 202 | Accepted |
The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The "202 Accepted" response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response should include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be enacted. |
|
| 203 | Provisional information | The returned metainformation in the Entity-Header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented may be a subset or superset of the original version. For example, including local annotation information about the resource may result in a superset of the metainformation known by the origin server. | |
| 204 | No content | The server has fulfilled the request but there is no new information to send back. If the client is a user agent, it should not change its document view. This response is primarily intended to allow input for scripts or other actions to take place without causing a change to the user agent's current document view. | |
| 205 | Reset Content | The server has fulfilled the request and the client should reset the form or input to a default state. This is often used on a user form submission to make sure the form is cleared so the user can submit again. | |
| 206 | Partial Content | The server has fulfilled the request with a range header meaning that the client wanted a certain part of the document. | |
| Redirection | 300 | Multiple choices | The requested resource is available at one or more locations and a preferred location could not be determined via content negotiation. Unless it was a HEAD request, the response must include an entity containing a formatted list of resource characteristics and locations from which the user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice may be performed automatically. |
| 301 | Moved permanently |
The requested resource has been assigned a new permanent URI and any future references to this resource must be done using the returned URI. Clients with link editing capabilities are encouraged to automatically relink references to the Request-URI to the new reference returned by the server, where possible. It is possible for the server to send this status code in response to a request using the PUT, POST, or DELETE methods. However, as this might change the conditions under which the request was issued, the user agent must not automatically redirect the request unless it can be confirmed by the user. |
|
| 302 | Moved temporarily |
The requested resource resides temporarily under a different URI. Since the redirection may be altered on occasion, the client should on future requests from the user continue to use the original Request-URI and not the URI returned in the URI-header field and Location fields. It is possible for the server to send this status code in response to a request using the PUT, POST, or DELETE methods. However, as this might change the conditions under which the request was issued, the user agent must not automatically redirect the request unless it can be confirmed by the user. |
|
| 303 | Method | This code is obsolete. | |
| 304 | Not modified | If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server shall respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers and which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. | |
| Client Error | 400 | Bad request | The request had bad syntax or was inherently impossible to be satisfied. The client is discouraged from repeating the request without modifications. |
| 401 | Unauthorized | The request requires user authentication. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client may repeat the request with a suitable Authorization header field. | |
| 402 | Payment required | This code is not currently supported, but is reserved for future use. | |
| 403 | Forbidden | The request is forbidden because of some reason that remains unknown to the client. Authorization will not help and the request should not be repeated. This status code can be used if the server does not want to make public why the request cannot be fulfilled. | |
| 404 | Not found | The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code "403 Forbidden" can be used instead. The "410 Gone" status code should be used if the server knows (through some internally configurable method) that an old resource is permanently unavailable and has no forwarding address. | |
| 405 | Method not allowed | The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response must include an Allow header containing a list of valid method's for the requested resource. | |
| 406 | None acceptable | The server has found a resource matching the Request-URI, but not one that satisfies the conditions identified by the Accept and Accept-Encoding request headers. The response must include (when applicable) the Content-Type, Content-Encoding, and Content-Language of the resource, and is encouraged to include the resource's complete metainformation. No Entity-Body can be included in the response. | |
| 407 | Proxy authentication required | This code is reserved for future use. It is similar to "401 Unauthorized", but indicates that the client must first authenticate itself with the proxy. HTTP/1.0 does not provide a means for proxy authentication -- this feature will be available in future versions. | |
| 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 |
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 may 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. If versioning is being used and the entity being PUT includes changes to a resource which conflict with those made by an earlier (third-party) request, the server may use the "409 Conflict" response to indicate that it can't complete the PUT. In this case, the response entity may 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. Clients with link editing capabilities are encouraged to delete references to the Request-URI (after user approval). If the server does not know (or has no facility to determine) whether or not the condition is permanent, the status code "404 Not Found" can be used instead. The "410 Gone" 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. | |
| 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 received an invalid response from the gateway or upstream server it accessed in attempting to complete 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 which will be alleviated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If no Retry-After is given, the client should handle the response as it would a "500 Internal Server Error". NOTE: The presence 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 did not receive a timely response from the gateway or upstream server it accessed in attempting to complete the request. |
Free Spam Protection Android ORM Simple Java Zip JMX using HTTP Great Eggnog Recipe