DEV Community

Cover image for Successful status codes
Emilie Gervais
Emilie Gervais

Posted on • Updated on

Successful status codes

Preface: A HTTP status code is issued from the server in response to a client's request made to the server. The five status code response classes are informational, successful, redirection, client error and server error.




Successful status codes

Successful status codes are returned when the browser request was successfully received, understood and processed by the server.

Table Of Contents


200 OK

Definition: The request has succeeded. Its response is cacheable. The meaning of this response depends on the HTTP request method the server received: For GET requests, the resource has been fetched and is transmitted in the message body; for HEAD requests, the entity headers are in the message body; for POST requests, the resource describing the result of the action is transmitted in the message body; for TRACE requests, the message body contains the request message as received by the server. For PUT and DELETE requests, a successful request is often not a 200, but a 204 No Content.

200 OK is defined in RFC 7231.


201 Created

Definition: The request has been fulfilled and resulted in a new resource being created. Successful creation occurred (via either POST or PUT). The new resource is returned in the body of the message, its location being either the URL of the request, or the content of the Location header.

201 Created is defined in RFC 7231.


202 Accepted

Definition: The request has been accepted for processing, but the processing has not been completed. It is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.

202 Accepted is defined in RFC 7231.


2013 Non-Authoritative Information

Definition: The request was successful but is returning a modified version of the origin's response resulting in an enclosed payload that has been modified by a transforming proxy from that of the origin server's 200 OK response. The 203 Non-Authoritative Information response is similar to the value 214 Transformation Applied of the Warning header code, which has the additional advantage of being applicable to responses with any status code.

2013 Non-Authoritative Information is defined in RFC 7231.


204 No Content

Definition: The request has succeeded, but the client doesn't need to go away from its current page. This response is cacheable by default and includes an ETag header. The common use case is to return 204 No Content as a result of a PUT request, updating a resource, without changing the current content of the page displayed to the user. If the resource is created, 201 Created is returned instead. If the page should be changed to the newly updated page, the 200 OK should be used instead.

204 No Content is defined in RFC 7231.


205 Reset Content

Definition: The request was successfully processed by the server, but is not returning any content. Similar to 204 No Content, but lets the client know that it should reset the document view.

205 Reset Content is defined in RFC 7231.


206 Partial Content

Definition: The request has succeeded, but the server is delivering only part of the resource due to a Range header sent by the client. If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment covers one range, with Content-Range and Content-Type describing it.

206 Partial Content is defined in RFC 7233.


207 Multi-Status (WebDAV)

Definition: The request has succeeded and the body of the server's response is by default an XML message which can contain a number of separate responses codes, depending on how many sub-requests were made. Useful for situations where multiple status codes might be appropriate.

207 Multi-Status (WebDAV) is defined in RFC 4918.


208 Already Reported (WebDAV)

Definition: The request has succeeded and contains a collection: Only one element will be reported with a 200 OK status. The others will be reported with a 208 status inside the response element <dav:propstat> to avoid repeatedly enumerating the internal members of multiple bindings to the same collection.

208 Already Reported (WebDAV) is defined in RFC 5842.


226 IM Used

The request has succeeded and the response sent by the server is a representaiton of the result of one or more instance-manipulations applied to the current instance.

226 IM Used is defined in RFC 3229.




Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Top comments (0)