2xx Success


2xx codes indicate successful responses usually this means the action requested by the client was received, understood and accepted successfully.

200 OK (RFC7231)

Everyone’s favorite response: the request has succeeded.

The response payload will depend on the request method used. The expected response body for the corresponding request method is as follows:

  • GET -  the headers and data corresponding to the requested resource
  • HEAD - just the headers corresponding the requested resource without the actual data
  • POST - the status of, or results obtained from the action

A 200 response should always have a payload but is not required, thus an origin server may generate a 200 with a zero length. To adhere to RFC standards a 204 should be generated in that case (exception CONNECT)

Cacheable by default by proxy servers and browsers. If not specified by Cloudflare cache controls,   static resources with this response will cache default for 2 hours at our edge.  

201 Created (RFC7231)

Request was successful and there are one or more new resources being created. The new resource’s location is expected to be present at either the Location header field or by the request’s URI. Typically, the payload will describe and reference links to the newly generated resource.

  • See RFC 7231 Section 7.2 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.

202 Accepted (RFC7231)

Request was accepted and is currently being processed by the origin server.  Depending on server’s specifications, the client may or may not act on the request while processing actually takes place.

203 Non-Authoritative Information (RFC7231)

Optional replacement of the 200 status code to explain the request was successful but did not come directly from the origin server. Original origin server response has been modified by a proxy or intermediate server. For example, 203’s could be used to inform the client that this resource has been cached at a proxy so a similar future request may or may not hit that cache server with that identical resource. Another example is when a header that is only applicable to the local origin server is stripped.

  • Is cacheable response by default, however, Cloudflare will not cache.
  • Cloudflare will never generate but may proxy from other proxies if present. Cloudflare respects origins responses with these exceptions: How does Cloudflare handle HTTP Request headers

204 No Content (RFC7231)

Requested actions were performed correctly at the origin server. The common use case is in document editors the “save” action is sent to the origin server, yet no payload is needed to be returned to the client. One still might want to alert the user that the save was successful.

  • There must never be a payload when returning a 204 response.
  • Is cacheable response by default, however, Cloudflare will not cache.

205 Reset Content (RFC7231)

Origin server suggests the client reset the view to its original state prior to the request. Often used in forms or other input submissions were a payload is sent in the request, the origin server operated successfully and now is notifying the browser that additional submissions are permitted.

  • A 205 response must never return a payload. Content-Length of 0 or chunked responses immediately followed by a close or zero-byte response allowed only.

206 Partial Content (RFC 7233)

Request for a part of a resource was successful and is located in the payload. The request must have indicated the range by either of the following:

  1. A single partial request with HTTP headers including Content Range followed by size. (If present in response header must be exactly equal to the octets in the payload) E.g. Content Range: bytes 21010-47021/47022
  2.  Multiple chunks with Content-Type: multipart/byteranges in HTTP header and including Content-Range fields for each part individually but not in the response HTTP header. Boundary also required as specified by RFC 7233 Section 4.1 e.g
 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

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

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

     ...the second range

 206’s are useful for clients processing larger files that require split or interrupted downloads with multiple simultaneous streams for improved latency.

Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.

Powered by Zendesk