HTTP Status Codes

httpstatuses.com is an easy to reference database of HTTP Status Codes with their definitions and helpful code references all in one place. Visit an individual status code via httpstatuses.com/code or browse the list below.

1×× Informational

100 Continue

100 Continue

The initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.

When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body1. The client ought to continue sending the request and discard the 100 response.

If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.


100 Code References

Rails HTTP Status Symbol :continue

Go HTTP Status Constant http.StatusContinue

Symfony HTTP Status Constant Response::HTTP_CONTINUE

Python2 HTTP Status Constant httplib.CONTINUE

Python3+ HTTP Status Constant http.client.CONTINUE

Python3.5+ HTTP Status Constant http.HTTPStatus.CONTINUE

101 Switching Protocols

101 Switching Protocols

The server understands and is willing to comply with the client's request, via the Upgrade header field1, for a change in the application protocol being used on this connection.

The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.

It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.


101 Code References

Rails HTTP Status Symbol :switching_protocols

Go HTTP Status Constant http.StatusSwitchingProtocols

Symfony HTTP Status Constant Response::HTTP_SWITCHING_PROTOCOLS

Python2 HTTP Status Constant httplib.SWITCHING_PROTOCOLS

Python3+ HTTP Status Constant http.client.SWITCHING_PROTOCOLS

Python3.5+ HTTP Status Constant http.HTTPStatus.SWITCHING_PROTOCOLS

102 Processing

102 Processing

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 (Processing) response. The server MUST send a final response after the request has been completed.

Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 Processing status code to indicate to the client that the server is still processing the method.


102 Code References

Rails HTTP Status Symbol :processing

Symfony HTTP Status Constant Response::HTTP_PROCESSING

2×× Success

200 OK

200 OK

The request has succeeded.

The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:

  • GET a representation of the target resource
  • HEAD the same representation as GET, but without the representation data
  • POST a representation of the status of, or results obtained from, the action;
    • PUT DELETE a representation of the status of the action;
    • OPTIONS a representation of the communications options;
    • TRACE a representation of the request message as received by the end server.

Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 No Content instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.

A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.


200 Code References

Rails HTTP Status Symbol :ok

Go HTTP Status Constant http.StatusOK

Symfony HTTP Status Constant Response::HTTP_OK

Python2 HTTP Status Constant httplib.OK

Python3+ HTTP Status Constant http.client.OK

Python3.5+ HTTP Status Constant http.HTTPStatus.OK

201 Created

201 Created

The request has been fulfilled and has resulted in one or more new resources being created.

The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.

The 201 response payload typically describes and links to the resource(s) created. See Section 7.2 of RFC7231 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.


201 Code References

Rails HTTP Status Symbol :created

Go HTTP Status Constant http.StatusCreated

Symfony HTTP Status Constant Response::HTTP_CREATED

Python2 HTTP Status Constant httplib.CREATED

Python3+ HTTP Status Constant http.client.CREATED

Python3.5+ HTTP Status Constant http.HTTPStatus.CREATED

202 Accepted

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.

There is no facility in HTTP for re-sending a status code from an asynchronous operation.

The 202 response is intentionally noncommittal. 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 representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.


202 Code References

Rails HTTP Status Symbol :accepted

Go HTTP Status Constant http.StatusAccepted

Symfony HTTP Status Constant Response::HTTP_ACCEPTED

Python2 HTTP Status Constant httplib.ACCEPTED

Python3+ HTTP Status Constant http.client.ACCEPTED

Python3.5+ HTTP Status Constant http.HTTPStatus.ACCEPTED

203 Non-authoritative Information

203 Non-authoritative Information

The request was successful but the enclosed payload has been modified from that of the origin server's 200 OK response by a transforming proxy1.

This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).

The 203 response is similar to the Warning code of 214 Transformation Applied2, which has the advantage of being applicable to responses with any status code.

A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls3.


203 Code References

Rails HTTP Status Symbol :non_authoritative_information

Go HTTP Status Constant http.StatusNonAuthoritativeInfo

Symfony HTTP Status Constant Response::HTTP_NON_AUTHORITATIVE_INFORMATION

Python2 HTTP Status Constant httplib.NON_AUTHORITATIVE_INFORMATION

Python3+ HTTP Status Constant http.client.NON_AUTHORITATIVE_INFORMATION

Python3.5+ HTTP Status Constant http.HTTPStatus.NON_AUTHORITATIVE_INFORMATION

204 No Content

204 No Content

The server has successfully fulfilled the request and that there is no additional content to send in the response payload body.

Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.

The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.

A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.

A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.


204 Code References

Rails HTTP Status Symbol :no_content

Go HTTP Status Constant http.StatusNoContent

Symfony HTTP Status Constant Response::HTTP_NO_CONTENT

Python2 HTTP Status Constant httplib.NO_CONTENT

Python3+ HTTP Status Constant http.client.NO_CONTENT

Python3.5+ HTTP Status Constant http.HTTPStatus.NO_CONTENT

205 Reset Content

205 Reset Content

The server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.

This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.

Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response: a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0; b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.


205 Code References

Rails HTTP Status Symbol :reset_content

Go HTTP Status Constant http.StatusResetContent

Symfony HTTP Status Constant Response::HTTP_RESET_CONTENT

Python2 HTTP Status Constant httplib.RESET_CONTENT

Python3+ HTTP Status Constant http.client.RESET_CONTENT

Python3.5+ HTTP Status Constant http.HTTPStatus.RESET_CONTENT

206 Partial Content

206 Partial Content

The server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field1.

If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload2, and a Content-Type header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead).

Within the header area of each body part in the multipart payload, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a Content-Type header field in a 200 OK response, the server SHOULD generate that same Content-Type field in the header area of each body part. For example:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding byte-range-spec appeared in the received Range header field. Since the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many small disjoint parts than it is to transfer the entire selected representation.

A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. However, a server MAY generate a multipart/byteranges payload with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges response MUST NOT generate a request that asks for multiple ranges.

When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that receives a multipart response MUST inspect the Content-Range header field present in each body part in order to determine which range is contained in that body part; a client cannot rely on receiving the same ranges that it requested, nor the same order that it requested.

When a 206 response is generated, the server MUST generate the following header fields, in addition to those required above, if the field would have been sent in a 200 OK response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.

If a 206 is generated in response to a request with an If-Range header field, the sender SHOULD NOT generate other representation header fields beyond those required above, because the client is understood to already have a prior response containing those header fields. Otherwise, the sender MUST generate all of the representation header fields that would have been sent in a 200 OK response to the same request.

A 206 response is cacheable by default; i.e., unless otherwise indicated by explicit cache controls3.


206 Code References

Rails HTTP Status Symbol :partial_content

Go HTTP Status Constant http.StatusPartialContent

Symfony HTTP Status Constant Response::HTTP_PARTIAL_CONTENT

Python2 HTTP Status Constant httplib.PARTIAL_CONTENT

Python3+ HTTP Status Constant http.client.PARTIAL_CONTENT

Python3.5+ HTTP Status Constant http.HTTPStatus.PARTIAL_CONTENT

207 Multi-Status

207 Multi-Status

A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.

The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements 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.

Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.

The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.

A Multi-Status response uses one out of two distinct formats for representing the status:

1. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole1. Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in RFC2616 Section 10.

2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in RFC4918 Section 9.1 and RFC4918 Section 9.2.


207 Code References

Rails HTTP Status Symbol :multi_status

Symfony HTTP Status Constant Response::HTTP_MULTI_STATUS

208 Already Reported

208 Already Reported

Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.

For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.

Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop1.

A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource.

For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request header2. Instead, a 508 Loop Detected status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response.


208 Code References

Symfony HTTP Status Constant Response::HTTP_ALREADY_REPORTED

226 IM Used

226 IM Used

The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the 226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification.

The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header field giving the entity tag of the current instance.

A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in section 10.6.

A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance.


226 Code References

Rails HTTP Status Symbol :im_used

Symfony HTTP Status Constant Response::HTTP_IM_USED

3×× Redirection

300 Multiple Choices

300 Multiple Choices

The target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers.

In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs1.

If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.

For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.

A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls2.

Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields3, each with a relationship of "alternate", though deployment is a chicken-and-egg problem.


300 Code References

Rails HTTP Status Symbol :multiple_choices

Go HTTP Status Constant http.StatusMultipleChoices

Symfony HTTP Status Constant Response::HTTP_MULTIPLE_CHOICES

Python2 HTTP Status Constant httplib.MULTIPLE_CHOICES

Python3+ HTTP Status Constant http.client.MULTIPLE_CHOICES

Python3.5+ HTTP Status Constant http.HTTPStatus.MULTIPLE_CHOICES

301 Moved Permanently

301 Moved Permanently

The target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.

Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.

The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 Temporary Redirect status code can be used instead.

A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.


301 Code References

Rails HTTP Status Symbol :moved_permanently

Go HTTP Status Constant http.StatusMovedPermanently

Symfony HTTP Status Constant Response::HTTP_MOVED_PERMANENTLY

Python2 HTTP Status Constant httplib.MOVED_PERMANENTLY

Python3+ HTTP Status Constant http.client.MOVED_PERMANENTLY

Python3.5+ HTTP Status Constant http.HTTPStatus.MOVED_PERMANENTLY

302 Found

302 Found

The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.

The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 Temporary Redirect status code can be used instead.


302 Code References

Rails HTTP Status Symbol :found

Go HTTP Status Constant http.StatusFound

Symfony HTTP Status Constant Response::HTTP_FOUND

Python2 HTTP Status Constant httplib.FOUND

Python3+ HTTP Status Constant http.client.FOUND

Python3.5+ HTTP Status Constant http.HTTPStatus.FOUND

303 See Other

303 See Other

The server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request.

A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.

This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.

A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.

Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field.


303 Code References

Rails HTTP Status Symbol :see_other

Go HTTP Status Constant http.StatusSeeOther

Symfony HTTP Status Constant Response::HTTP_SEE_OTHER

Python2 HTTP Status Constant httplib.SEE_OTHER

Python3+ HTTP Status Constant http.client.SEE_OTHER

Python3.5+ HTTP Status Constant http.HTTPStatus.SEE_OTHER

304 Not Modified

304 Not Modified

A conditional GET or HEAD request has been received and would have resulted in a 200 OK response if it were not for the fact that the condition evaluated to false.

In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a 200 OK response.

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 OK response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).

Requirements on a cache that receives a 304 response are defined in Section 4.3.4 of RFC7234. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client.

A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.


304 Code References

Rails HTTP Status Symbol :not_modified

Go HTTP Status Constant http.StatusNotModified

Symfony HTTP Status Constant Response::HTTP_NOT_MODIFIED

Python2 HTTP Status Constant httplib.NOT_MODIFIED

Python3+ HTTP Status Constant http.client.NOT_MODIFIED

Python3.5+ HTTP Status Constant http.HTTPStatus.NOT_MODIFIED

305 Use Proxy

305 Use Proxy

Defined in a previous version of this specification and is now deprecated, due to security concerns regarding in-band configuration of a proxy.


307 Temporary Redirect

307 Temporary Redirect

The target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.

Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.

The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).

Note: This status code is similar to 302 Found, except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 Moved Permanently (RFC7238, however, proposes defining the status code 308 Permanent Redirect for this purpose).


307 Code References

Rails HTTP Status Symbol :temporary_redirect

Go HTTP Status Constant http.StatusTemporaryRedirect

Symfony HTTP Status Constant Response::HTTP_TEMPORARY_REDIRECT

Python2 HTTP Status Constant httplib.TEMPORARY_REDIRECT

Python3+ HTTP Status Constant http.client.TEMPORARY_REDIRECT

Python3.5+ HTTP Status Constant http.HTTPStatus.TEMPORARY_REDIRECT

308 Permanent Redirect

308 Permanent Redirect

The target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.

Clients with link editing capabilities ought to automatically re-link references to the effective request URI1 to one or more of the new references sent by the server, where possible.

The server SHOULD generate a Location header field2 in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).

A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls3.

Note: This status code is similar to 301 Moved Permanently, except that it does not allow changing the request method from POST to GET.


308 Code References

Symfony HTTP Status Constant Response::HTTP_PERMANENTLY_REDIRECT

4×× Client Error

400 Bad Request

400 Bad Request

The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).


400 Code References

Rails HTTP Status Symbol bad_request

Go HTTP Status Constant http.StatusBadRequest

Symfony HTTP Status Constant Response::HTTP_BAD_REQUEST

Python2 HTTP Status Constant httplib.BAD_REQUEST

Python3+ HTTP Status Constant http.client.BAD_REQUEST

Python3.5+ HTTP Status Constant http.HTTPStatus.BAD_REQUEST

401 Unauthorized

401 Unauthorized

The request has not been applied because it lacks valid authentication credentials for the target resource.

The server generating a 401 response MUST send a WWW-Authenticate header field1 containing at least one challenge applicable to the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field2. 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 agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.


401 Code References

Rails HTTP Status Symbol :unauthorized

Go HTTP Status Constant http.StatusUnauthorized

Symfony HTTP Status Constant Response::HTTP_UNAUTHORIZED

Python2 HTTP Status Constant httplib.UNAUTHORIZED

Python3+ HTTP Status Constant http.client.UNAUTHORIZED

Python3.5+ HTTP Status Constant http.HTTPStatus.UNAUTHORIZED

402 Payment Required

402 Payment Required

Reserved for future use.


402 Code References

Rails HTTP Status Symbol :payment_required

Go HTTP Status Constant http.StatusPaymentRequired

Symfony HTTP Status Constant Response::HTTP_PAYMENT_REQUIRED

Python2 HTTP Status Constant httplib.PAYMENT_REQUIRED

Python3+ HTTP Status Constant http.client.PAYMENT_REQUIRED

Python3.5+ HTTP Status Constant http.HTTPStatus.PAYMENT_REQUIRED

403 Forbidden

403 Forbidden

The server understood the request but refuses to authorize it.

A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 Not Found.


403 Code References

Rails HTTP Status Symbol :forbidden

Go HTTP Status Constant http.StatusForbidden

Symfony HTTP Status Constant Response::HTTP_FORBIDDEN

Python2 HTTP Status Constant httplib.FORBIDDEN

Python3+ HTTP Status Constant http.client.FORBIDDEN

Python3.5+ HTTP Status Constant http.HTTPStatus.FORBIDDEN

404 Not Found

404 Not Found

The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 Gone status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.


404 Code References

Rails HTTP Status Symbol :not_found

Go HTTP Status Constant http.StatusNotFound

Symfony HTTP Status Constant Response::HTTP_NOT_FOUND

Python2 HTTP Status Constant httplib.NOT_FOUND

Python3+ HTTP Status Constant http.client.NOT_FOUND

Python3.5+ HTTP Status Constant http.HTTPStatus.NOT_FOUND

405 Method Not Allowed

405 Method Not Allowed

The method received in the request-line is known by the origin server but not supported by the target resource.

The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.

A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.


405 Code References

Rails HTTP Status Symbol :method_not_allowed

Go HTTP Status Constant http.StatusMethodNotAllowed

Symfony HTTP Status Constant Response::HTTP_METHOD_NOT_ALLOWED

Python2 HTTP Status Constant httplib.METHOD_NOT_ALLOWED

Python3+ HTTP Status Constant http.client.METHOD_NOT_ALLOWED

Python3.5+ HTTP Status Constant http.HTTPStatus.METHOD_NOT_ALLOWED

406 Not Acceptable

406 Not Acceptable

The target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request1, and the server is unwilling to supply a default representation.

The server SHOULD generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in RFC7231 Section 6.4.1.


406 Code References

Rails HTTP Status Symbol :not_acceptable

Go HTTP Status Constant http.StatusNotAcceptable

Symfony HTTP Status Constant Response::HTTP_NOT_ACCEPTABLE

Python2 HTTP Status Constant httplib.NOT_ACCEPTABLE

Python3+ HTTP Status Constant http.client.NOT_ACCEPTABLE

Python3.5+ HTTP Status Constant http.HTTPStatus.NOT_ACCEPTABLE

407 Proxy Authentication Required

407 Proxy Authentication Required

Similar to 401 Unauthorized, but it indicates that the client needs to authenticate itself in order to use a proxy.

The proxy MUST send a Proxy-Authenticate header field1 containing a challenge applicable to that proxy for the target resource. The client MAY repeat the request with a new or replaced Proxy-Authorization header field2.


407 Code References

Rails HTTP Status Symbol :proxy_authentication_required

Go HTTP Status Constant http.StatusProxyAuthRequired

Symfony HTTP Status Constant Response::HTTP_PROXY_AUTHENTICATION_REQUIRED

Python2 HTTP Status Constant httplib.PROXY_AUTHENTICATION_REQUIRED

Python3+ HTTP Status Constant http.client.PROXY_AUTHENTICATION_REQUIRED

Python3.5+ HTTP Status Constant http.HTTPStatus.PROXY_AUTHENTICATION_REQUIRED

408 Request Timeout

408 Request Timeout

The server did not receive a complete request message within the time that it was prepared to wait.

A server SHOULD send the "close" connection option1 in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.


408 Code References

Rails HTTP Status Symbol :request_timeout

Go HTTP Status Constant http.StatusRequestTimeout

Symfony HTTP Status Constant Response::HTTP_REQUEST_TIMEOUT

Python2 HTTP Status Constant httplib.REQUEST_TIMEOUT

Python3+ HTTP Status Constant http.client.REQUEST_TIMEOUT

Python3.5+ HTTP Status Constant http.HTTPStatus.REQUEST_TIMEOUT

409 Conflict

409 Conflict

The request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request.

The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.


409 Code References

Rails HTTP Status Symbol :conflict

Go HTTP Status Constant http.StatusConflict

Symfony HTTP Status Constant Response::HTTP_CONFLICT

Python2 HTTP Status Constant httplib.CONFLICT

Python3+ HTTP Status Constant http.client.CONFLICT

Python3.5+ HTTP Status Constant http.HTTPStatus.CONFLICT

410 Gone

410 Gone

The target resource is no longer available at the origin server and that this condition is likely to be permanent.

If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 Not Found ought to be used instead.

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 associated with the origin 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 discreti

  • http-status-codes