http-status-code/json/rfc1945.json

Easy access to HTTP Status Codes

//  Hypertext Transfer Protocol - HTTP/1.0
//  http://tools.ietf.org/html/1945

{
	//  2xx  -  Successful

	//   The request has succeeded.
	"200": "OK",

	//   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 entity of the response. The origin server
	//  should create the resource before using this Status-Code. If the action cannot be carried out
	//  immediately, the server must include in the response body a description of when the resource will be
	//  available; otherwise, the server should respond with 202 (accepted). Of the methods defined by this
	//  specification, only POST can create a resource.
	"201": "Created",

	//   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.
	"202": "Accepted",

	//   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 from that which caused the request to be
	//  generated. 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 active document view. The response may include
	//  new metainformation in the form of entity headers, which should apply to the document currently in
	//  the user agent's active view.
	"204": "No Content",

	//  3xx  -  Redirection

	//   This response code is not directly used by HTTP/1.0 applications, but serves as the default for
	//  interpreting the 3xx class of responses. The requested resource is available at one or more
	//  locations. Unless it was a HEAD request, the response should include an entity containing a list of
	//  resource characteristics and locations from which the user or user agent can choose the one most
	//  appropriate. If the server has a preferred choice, it should include the URL in a Location field;
	//  user agents may use this field value for automatic redirection.
	"300": "Multiple Choices",

	//   The requested resource has been assigned a new permanent URL and any future references to this
	//  resource should be done using that URL. Clients with link editing capabilities should automatically
	//  relink references to the Request-URI to the new reference returned by the server, where possible.
	//  The new URL must be given by the Location field in the response. Unless it was a HEAD request, the
	//  Entity-Body of the response should contain a short note with a hyperlink to the new URL. If the 301
	//  status code is received in response to a request using the POST method, 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.
	"301": "Moved Permanently",

	//   The requested resource resides temporarily under a different URL. Since the redirection may be
	//  altered on occasion, the client should continue to use the Request-URI for future requests. The URL
	//  must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body
	//  of the response should contain a short note with a hyperlink to the new URI(s). If the 302 status
	//  code is received in response to a request using the POST method, 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.
	"302": "Moved Temporarily",

	//   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 must
	//  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 or which may have
	//  changed independently of the entity's Last-Modified date. Examples of relevant header fields
	//  include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field
	//  values given in the 304 response.
	"304": "Not Modified",

	//  4xx  -  User Error

	//   The request could not be understood by the server due to malformed syntax. The client should not
	//  repeat the request without modifications.
	"400": "Bad Request",

	//   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. If the request already included Authorization credentials,
	//  then the 401 response indicates that authorization has been refused for those credentials. If the
	//  401 response contains the same challenge as the prior response, and the user agent has already
	//  attempted authentication at least once, then the user should be presented the entity that was given
	//  in the response, since that entity may include relevant diagnostic
	//  information.
	"401": "Unauthorized",

	//   The server understood the request, but is refusing to fulfill it. Authorization will not help and
	//  the request should not be repeated. If the request method was not HEAD and the server wishes to make
	//  public why the request has not been fulfilled, it should describe the reason for the refusal in the
	//  entity body. 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.
	"403": "Forbidden",

	//   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.
	"404": "Not Found",

	//  5xx  -  Server Error

	//   The server encountered an unexpected condition which prevented it from fulfilling
	//  the request.
	"500": "Internal Server Error",

	//   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.
	"501": "Not Implemented",

	//   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.
	"502": "Bad Gateway",

	//   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.
	"503": "Service Unavailable"
}