Status Codes 2xx (Successful)

Types of HTTP Status Codes

Before moving on to 1xx status codes, it is best to know that there are five categories into which we can divide HTTP response codes.

1xx Status Codes for information.
2xx Status Codes indicate that a request has been processed properly.
3xx Status Codes for redirection advise the client that the requested resource is accessible elsewhere on the server.
4xx Status Codes for client errors primarily comes from the browser, because the required parameters to visit the requested URL are lacking.
5xx Status Codes for Server Errors indicate that the request could not be processed.

Introduction

When the request is shown as 2xx Successful, the browser has successfully received the requested data. This is typically the one you want to see because it indicates that the request was successful and that it was acknowledged, comprehended, and accepted.

It is your responsibility as the website owner to ensure that all pages and resources (such as photos, videos, etc.) return a 2xx status code. This indicates that browsers can successfully access it and that users of your website may view and interact with it.

200 OK Status Code

The request method determines the payload that is provided in a 200 response. The payload's intended meaning for the techniques described by this specification can be summed up as follows:

GET the target resource's representation;
POST a representation of how things are going or what the action has accomplished;
HEAD the same representation as GET, minus the representation data;
PUT DELETE a representation of action's status;
OPTIONS a representation of the communications options;
TRACE a representation of the request message as received by the end server

A 200 response always has a payload, except responses to CONNECT, however an origin server MAY produce a payload body with zero length. An origin server should send 204 No Content if no payload is required. No payload is permitted for CONNECT, since the successful outcome is a tunnel that starts right after the 200 response header section.

A 200 response is automatically cacheable unless the method specification or explicit cache controls1 specified otherwise.

References for Code 200

HTTP Status Symbol for Rails :ok
HTTP Status Constant for Symfony Response::HTTP_OK
HTTP Status Constant for Go http.StatusOK
HTTP Status Constant for Python2 httplib.OK
HTTP Status Constant for Python3.5+ http.HTTPStatus.OK
HTTP Status Constant for Python3+ http.client.OK

201 Created Status Code

If a Location header field is present in the response, it can be used to determine the principal resource created by the request, otherwise, the effective request URI is used.

The 201 response payload often provides a description of and links to the generated resource(s).

References for Code 201

HTTP Status Symbol for Rails :created
HTTP Status Constant for Python3+ http.client.CREATED
HTTP Status Constant for Symfony Response::HTTP_CREATED
HTTP Status Constant for Python2 httplib.CREATED
HTTP Status Constant for Python3.5+ http.HTTPStatus.CREATED
HTTP Status Constant for Go http.StatusCreated

202 Accepted Status Code

The HTTP protocol does not support the ability to resend a status code from an asynchronous operation.

The 202 response is purposefully vague. Its goal is to enable a server to accept a request for an additional process (perhaps a batch-oriented process that is only executed once every day). It doesn't require the user agent's connection to the server, as it remain active until the process is finished. A status monitor that can give the user an idea of when the request will be fulfilled should be pointed to (or embedded) in the representation that is sent along with this response.

References for Code 202

HTTP Status Symbol for Rails :accepted
HTTP Status Constant for Python2 httplib.ACCEPTED
HTTP Status Constant for Symfony Response::HTTP_ACCEPTED
HTTP Status Constant for Go http.StatusAccepted
HTTP Status Constant for Python3+ http.client.ACCEPTED
HTTP Status Constant for Python3.5+ http.HTTPStatus.ACCEPTED

203 Non-Authoritative Information Status Code

Given that this information may have an impact on future decisions regarding the content, the proxy is able to inform receivers when a transformation has been made by using this status code. For instance, subsequent requests for the content's cache validation might only be applicable along the same request path (through the same proxies).

The 203 response is comparable to the Warning code of 214 Transformation Applied, which has the benefit of being applicable to responses with any status code.

Unless the method specification or explicit cache controls state otherwise, a 203 response is cacheable by default.

References for Code 203

HTTP Status Symbol for Rails :non_authoritative_information
HTTP Status Constant for Python2 httplib.NON_AUTHORITATIVE_INFORMATION
HTTP Status Constant for Go http.StatusNonAuthoritativeInfo
HTTP Status Constant for Python3.5+ http.HTTPStatus.NON_AUTHORITATIVE_INFORMATION
HTTP Status Constant for Python3+ http.client.NON_AUTHORITATIVE_INFORMATION
HTTP Status Constant for Symfony Response::HTTP_NON_AUTHORITATIVE_INFORMATION

204 No Content Status Code

The target resource and the representation that was chosen after the requested action was taken are both included in the response header fields.

For instance, if a PUT request returns a 204 status code and the response includes an ETag header field, the PUT was successful, and the entity-tag for the updated representation of the target resource is contained in the ETag field-value.

While hinting that the user agent does not need to leave its current “document view,” the 204 response allows a server to show that the action has been successfully implemented to the target resource (if any). The server assumes that the user agent will apply any new or modified metadata in the response to its active representation and give the user some signal of the success in accordance with its own interface.

For instance, a 204 status code is frequently used with document editing interfaces and corresponds to a “save” action, ensuring that the user can continue to modify the document after it has been saved. Additionally, it is widely used with interfaces that anticipate the use of automated data transfers, such as distributed version control systems.

A 204 response cannot include a message body, and is thus terminated by the first empty line following the header fields.

A 204 response is cacheable by default, unless the method description or explicit cache controls specify otherwise1.

References for Code 204

HTTP Status Symbol for Rails :no_content
HTTP Status Constant for Python2 httplib.NO_CONTENT
HTTP Status Constant for Go http.StatusNoContent
HTTP Status Constant for Python3+ http.client.NO_CONTENT
HTTP Status Constant for Symfony Response::HTTP_NO_CONTENT
HTTP Status Constant for Python3.5+ http.HTTPStatus.NO_CONTENT

205 Reset Content Status Code

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

A server MUST NOT provide a payload in a 205 response, since the status code 205 means that no extra material will be delivered. For a 205 response, a server MUST carry out one of the following actions: a) include a Content-Length header field with a value of 0 to indicate a zero-length body; b) include a Transfer-Encoding header field with a value of chunked and a message body made up of a single zero-length chunk; or c) immediately cut off the connection after sending the blank line that ends the header section to indicate a zero-length payload.

References for Code 205

HTTP Status Symbol for Rails :reset_content
HTTP Status Constant for Symfony Response::HTTP_RESET_CONTENT
HTTP Status Constant for Python2 httplib.RESET_CONTENT
HTTP Status Constant for Python3.5+ http.HTTPStatus.RESET_CONTENT
HTTP Status Constant for Go http.StatusResetContent
HTTP Status Constant for Python3+ http.client.RESET_CONTENT

206 Partial Content Status Code

The server producing the 206 response MUST supply a Content-Range header field indicating what range of the chosen format is enclosed, as well as a payload made up of the range, if only one part is being sent. For instance:

HTTP/1.1 206 Partial Content
Date: Thu, 28 July 2022 10:25:24 GMT
Last-Modified: Thu, 28 July 2022 10:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

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

The server producing the 206 answer MUST produce a "multipart/byteranges" payload and a Content-Type header field containing the multipart/byteranges media type and its necessary boundary parameter if multiple parts are being sent. A server MUST NOT create a Content-Range header field in the HTTP header section of a multiple part response to prevent confusion with single-part answers (this field will be sent in each part instead).

The server MUST provide a Content-Range header field that corresponds to the range being encapsulated in each body part of the multipart payload in the header region of each body part. The server SHOULD produce the same Content-Type header field in the header section of each body portion if the chosen representation would have had one in a 200 OK response. For instance:

HTTP/1.1 206 Partial Content
Date: Thu, 28 July 2022 10:25:24 GMT
Last-Modified: Thu, 28 July 2022 10:25:24 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--

Regardless of the sequence in which the matching byte-range-spec occurred in the received Range header field, a server MAY merge any of the requested ranges that overlap or are separated by a gap that is less than the overhead of delivering multiple parts. It can be less efficient to transfer numerous small, disconnected parts than it is to transfer the entire chosen representation because the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on the media type of the selected representation and the boundary parameter length chosen.

Since a client who does not ask for many parts might not be able to handle multipart replies, a server MUST NOT produce a multipart response to a request for a single range. However, if several ranges were requested, but only one range was discovered to be satisfiable or only one range remained after coalescing, a server MAY create a multipart/byteranges payload with only a single body part. A client SHOULD NOT create a request with multiple ranges if it cannot handle a multipart/byteranges answer.

The server SHOULD deliver the components of a multipart response payload in the same order as the relevant byte-range-spec appeared in the received Range header field, except any ranges that were deemed insufficient or that were combined with other ranges. A client cannot rely on receiving the same ranges or in the same order that it requested when it receives a multipart response; instead, the client MUST examine the Content-Range header field provided in each body part to see which range is represented there.

In addition to those that are necessary above, the server MUST send the following header fields in a 206 response if a 200 OK response would have sent the same field: Date, Content-Location, Cache-Control, ETag, Expires, and Vary.

The sender SHOULD NOT create additional representation header fields beyond those necessary above in response to a request with an If-Range header field, as the client is assumed to have previously received a prior response containing those header fields. A 200 OK response to the identical request would have included all of the representation header fields, which the sender MUST generate in the absence of that.

If no explicit cache controls are present, a 206 answer is cacheable by default3.

References for Code 206

HTTP Status Constant for Python2 httplib.PARTIAL_CONTENT
HTTP Status Constant for Go http.StatusPartialContent
HTTP Status Constant for Python3+ http.client.PARTIAL_CONTENT
HTTP Status Constant for Symfony Response::HTTP_PARTIAL_CONTENT
HTTP Status Constant for Python3.5+ http.HTTPStatus.PARTIAL_CONTENT
HTTP Status Symbol for Rails :partial_content

207 Multi-Status Code Response

A text/xml or application/xml HTTP entity with the'multistatus' root element makes up the default Multi-Status response body. Additional elements include status codes from the 200, 300, 400, and 500 series that were generated during the method call. A "response" XML element SHOULD NOT contain 100 series status codes.

The recipient must read the contents of the multistatus response body for more details regarding the success or failure of the method execution, even when the overall response status code is "207". The reaction COULD be applied in situations involving full or partial success as well as failure.

The "multistatus" root element has zero or more "response" elements, each containing details about a distinct resource, in any sequence. An 'href' element MUST be present in every'response' element to specify the resource.

One of two different forms is used by a Multi-Status response to express the status:

The state of the message execution for the designated resource as a whole is shown via a "status" element that is a child of the "response" element. Certain method descriptions give details on particular status codes that clients should be ready to see in a response. Clients MUST, however, be able to manage additional status codes using the general guidelines.
The format has been expanded for PROPFIND and PROPPATCH, using the 'propstat' element in place of the'status' element to provide information about specific attributes of a resource.

References for Code 207

HTTP Status Symbol for Rails :multi_status
HTTP Status Constant for Symfony Response::HTTP_MULTI_STATUS

208 Already Reported Status Code

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

It is important to keep in mind that the 208 status will only appear for "Depth: infinity" requests and that it is crucial when many collection bindings result in a bind loop.

In order to ensure that they can precisely rebuild the binding structure of a collection with numerous bindings to a single resource, a client can ask for the DAV:resource-id attribute in a PROPFIND request.

To maintain backward compatibility with clients who are ignorant of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has expressed support for this specification using the "DAV" request header. Instead, when a binding loop is found, a 508 Loop Detected status ought to be given. This enables the server to either send the 508 as the middle-level return status or as the top-level return status if it finds the error after starting the response or while streaming out a multistatus response.

References for Code 208

HTTP Status Constant for Symfony Response::HTTP_ALREADY_REPORTED

226 IM Used Status Code

It's possible that this response can only be used in conjunction with other recent or future responses, depending on the instance manipulation at hand(s). The headers of the resulting instance, if this is the case, are created by merging the headers from the 226 response and the other instances while adhering to the guidelines.

A-IM header field stating at least one instance-manipulation MUST have been present in the request. An Etag header field containing the entity tag of the current instance MUST be included in the response.

A response that has a status code of 226 MAY be cached and used in response to a subsequent request, the HTTP expiration mechanism, and any Cache-Control headers.

A cache MAY generate a cache entry for the current instance using a response with a status code of 226 together with a cache entry for the base instance.