• Час читання ~11 хв
  • 18.10.2021
Informational 1xx
The 1xx (Informational) class of status code indicates an interim
   response for communicating connection status or request progress
   prior to completing the requested action and sending a final
   response. 1xx responses are terminated by the first empty line after
   the status-line (the empty line signaling the end of the header
   section).  Since HTTP/1.0 did not define any 1xx status codes, a
   server MUST NOT send a 1xx response to an HTTP/1.0 client.

   A client MUST be able to parse one or more 1xx responses received
   prior to a final response, even if the client does not expect one.  A
   user agent MAY ignore unexpected 1xx responses.

   A proxy MUST forward 1xx responses unless the proxy itself requested
   the generation of the 1xx response.  For example, if a proxy adds an
   "Expect: 100-continue" field when it forwards a request, then it need
   not forward the corresponding 100 (Continue) response(s).
100 Continue
The 100 (Continue) status code indicates that 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 body, as described in Section 5.1.1.
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.
Section 6.2.1
101 Switching Protocols
The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via
the Upgrade header field (Section 6.7 of [RFC7230]), 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
Section 6.2.2 
Successful 2xx
The 2xx (Successful) class of status code indicates that the client's
   request was successfully received, understood, and accepted.
200 OK
The 200 (OK) status code indicates that 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

   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

   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 controls (see
   Section 4.2.2 of [RFC7234]).
Section 6.3.1
201 Created
The 201 (Created) status code indicates that 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 for a discussion of the meaning
   and purpose of validator header fields, such as ETag and
   Last-Modified, in a 201 response.
Section 6.3.2
202 Accepted
The 202 (Accepted) status code indicates that 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

   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.
Section 6.3.3
203 Non-Authoritative Information
The 203 (Non-Authoritative Information) status code indicates that
   the request was successful but the enclosed payload has been modified
   from that of the origin server's 200 (OK) response by a transforming
   proxy (Section 5.7.2 of [RFC7230]).  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
   Applied (Section 5.5 of [RFC7234]), 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 controls (see
   Section 4.2.2 of [RFC7234]).
Section 6.3.4 
204 No Content 
   The 204 (No Content) status code indicates that 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 controls (see
   Section 4.2.2 of [RFC7234]).
Section 6.3.5 
205 Reset Content
The 205 (Reset Content) status code indicates that 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.
Section 6.3.6
206 Partial Content   Section 4.1 of [RFC7233]
Redirection 3xx
The 3xx (Redirection) class of status code indicates that further
   action needs to be taken by the user agent in order to fulfill the
   request.  If a Location header field (Section 7.1.2) is provided, the
   user agent MAY automatically redirect its request to the URI
   referenced by the Location field value, even if the specific status
   code is not understood.  Automatic redirection needs to done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

   There are several types of redirects:

   1.  Redirects that indicate the resource might be available at a
       different URI, as provided by the Location field, as in the
       status codes 301 (Moved Permanently), 302 (Found), and 307
       (Temporary Redirect).

   2.  Redirection that offers a choice of matching resources, each
       capable of representing the original request target, as in the
       300 (Multiple Choices) status code.

   3.  Redirection to a different resource, identified by the Location
       field, that can represent an indirect response to the request, as
       in the 303 (See Other) status code.

   4.  Redirection to a previously cached result, as in the 304 (Not
       Modified) status code.

      Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and
      302 (Found) were defined for the first type of redirect
      ([RFC1945], Section 9.3).  Early user agents split on whether the
      method applied to the redirect target would be the same as the
      original request or would be rewritten as GET.  Although HTTP
      originally defined the former semantics for 301 and 302 (to match
      its original implementation at CERN), and defined 303 (See Other)
      to match the latter semantics, prevailing practice gradually
      converged on the latter semantics for 301 and 302 as well.  The
      first revision of HTTP/1.1 added 307 (Temporary Redirect) to
      indicate the former semantics without being impacted by divergent
      practice.  Over 10 years later, most user agents still do method
      rewriting for 301 and 302; therefore, this specification makes
      that behavior conformant when the original request is POST.

   A client SHOULD detect and intervene in cyclical redirections (i.e.,
   "infinite" redirection loops).

      Note: An earlier version of this specification recommended a
      maximum of five redirections ([RFC2068], Section 10.3).  Content
      developers need to be aware that some clients might implement such
      a fixed limitation.
   | Code | Reason-Phrase                 | Defined in...            |

   | 300  | Multiple Choices              | Section 6.4.1            |
   | 301  | Moved Permanently             | Section 6.4.2            |
   | 302  | Found                         | Section 6.4.3            |
   | 303  | See Other                     | Section 6.4.4            |
   | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
   | 305  | Use Proxy                     | Section 6.4.5            |
   | 307  | Temporary Redirect            | Section 6.4.7            |
   | 400  | Bad Request                   | Section 6.5.1            |
   | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
   | 402  | Payment Required              | Section 6.5.2            |
   | 403  | Forbidden                     | Section 6.5.3            |
   | 404  | Not Found                     | Section 6.5.4            |
   | 405  | Method Not Allowed            | Section 6.5.5            |
   | 406  | Not Acceptable                | Section 6.5.6            |
   | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
   | 408  | Request Timeout               | Section 6.5.7            |
   | 409  | Conflict                      | Section 6.5.8            |
   | 410  | Gone                          | Section 6.5.9            |
   | 411  | Length Required               | Section 6.5.10           |
   | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
   | 413  | Payload Too Large             | Section 6.5.11           |
   | 414  | URI Too Long                  | Section 6.5.12           |
   | 415  | Unsupported Media Type        | Section 6.5.13           |
   | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
   | 417  | Expectation Failed            | Section 6.5.14           |
   | 426  | Upgrade Required              | Section 6.5.15           |
   | 500  | Internal Server Error         | Section 6.6.1            |
   | 501  | Not Implemented               | Section 6.6.2            |
   | 502  | Bad Gateway                   | Section 6.6.3            |
   | 503  | Service Unavailable           | Section 6.6.4            |
   | 504  | Gateway Timeout               | Section 6.6.5            |
   | 505  | HTTP Version Not Supported    | Section 6.6.6            |


No comments yet
Yurij Finiv

Yurij Finiv

Full stack

Про мене

Professional Fullstack Developer with extensive experience in website and desktop application development. Proficient in a wide range of tools and technologies, including Bootstrap, Tailwind, HTML5, CSS3, PUG, JavaScript, Alpine.js, jQuery, PHP, MODX, and Node.js. Skilled in website development using Symfony, MODX, and Laravel. Experience: Contributed to the development and translation of MODX3 i...

Про автора CrazyBoy49z
Ukraine, Lutsk