• HTTP status code is part of the first line of the server response. It is an integer of three Arabic numerals. The first digit indicates the status class. The response code is usually followed by an explanatory phrase in English, separated by a space, which explains to the person the reason for this particular response.

• 100 Continue — The server is satisfied with the initial request information, the client may continue to forward headers. Introduced in HTTP/1.1.
  
  101 Switching Protocols — The server is offering to select a different protocol that is more appropriate for the resource. The protocols offered by the server are specified in the Update header line, if the server's proposed protocol is acceptable to the client, it sends a new request specifying the new protocol. Introduced in the protocol version HTTP/1.1.
  
  102 Processing — The request has been accepted, but it will take a long time to process. Used by the server to prevent the client from disconnecting due to a timeout. When the client receives such a response, it should reset the timer and wait for the next command as normal. Introduced in WebDAV.
  
  105 Name Not Resolved - An error occurred while resolving the domain name due to an invalid or missing DNS server IP address.

• 200 OK — A successful request. If the client requested any data, it is in the header and/or body of the message. Introduced in HTTP/1.0.
  
  201 Created — As a result of the successful execution of the request, a new resource was created. The server should specify its location in the Location header. The server is also recommended to specify the characteristics of the created resource in the header (for example, in the Content-Type field).
  
  If the server is not sure that the resource will actually exist by the time the client receives this message, it is better to use a response with the 202 code. Introduced in HTTP/1.0.
  
  202 Accepted — The request was accepted for processing, but it is not complete. The client does not have to wait for the final transmission of the message, since a very long process may be started. Introduced in HTTP/1.0.
  
  203 Non-Authoritative Information — Similar to 200, but in this case the information provided was not taken from the primary source (backup, another server, etc.) and may therefore be outdated. Introduced in HTTP/1.1.
  
  204 No Content — The server successfully processed the request, but the response included only headers without a message body. The client should not update the document content, but may apply the received metadata to it. Introduced in HTTP/1.0.
  
  205 Reset Content — The server requests that the client reset the user-entered data. The server does not transmit the message body, and the document does not need to be updated. Introduced in HTTP/1.1.
  
  206 Partial Content — The server successfully completed a partial GET request, returning only part of the message. The server specifies the byte ranges of the content in the Content-Range header. Special attention should be paid to caching when working with such responses. Introduced in HTTP/1.1.
  
  207 Multi-Status — The server transmits the results of several independent operations at once. They are placed in the message body itself as an XML document with the multistatus object. It is not recommended to place 1xx series statuses in this object because they are meaningless and redundant. Introduced in WebDAV.
  
  226 IM Used — The A-IM header from the client was successfully received and the server returns the content taking into account the specified parameters. Introduced in RFC 3229 to extend the HTTP protocol with support for delta encoding.

• 300 Multiple Choices — The specified URI has several possible resources, based on MIME type, language, or other characteristics. The server passes a list of alternatives with the message, allowing the client to make a selection automatically or the user to do so. Introduced in HTTP/1.0.
  
  301 Moved Permanently — The requested document has been permanently moved to a new URI, specified in the Location header field. Some clients behave incorrectly when processing this code. Introduced in HTTP/1.0.
  
  302 Moved Temporarily / Found — The requested document is temporarily available at a different URI, specified in the Location header field. This code can be used, for example, in server-driven content negotiation. Some clients behave incorrectly when processing this code. Introduced in HTTP/1.0.
  
  303 See Other — The document at the requested URI should be requested using the address in the Location header field using the GET method, even though the first resource was requested using a different method. This code was introduced along with 307 to avoid ambiguity, so that the server can be sure that the next resource will be requested using the GET method.
  
  For example, a web page has a text input field for quick navigation and searching. After entering the data, the browser makes a POST request, including the entered text in the message body.
  
  If a document with the entered name is found, the server responds with code 303, specifying its permanent address in the Location header. Then the browser is guaranteed to request it using the GET method to obtain the contents. Otherwise, the server will simply return the page with the search results to the client. Introduced in HTTP/1.1.
  
  304 Not Modified — The server returns this code if the client requested a document using the GET method, used the If-Modified-Since or If-None-Match header, and the document has not changed since the specified time. In this case, the server message must not contain a body. Introduced in HTTP/1.0. Check the 304 Not Modified code.
  
  305 Use Proxy — The request to the requested resource must be made through a proxy server whose URI is specified in the Location field of the header. This response code may only be used by original HTTP servers (not proxies). Introduced in HTTP/1.1.
  
  306 (Reserved, code only used in earlier specifications) — A previously used response code, currently reserved. Mentioned in RFC 2616 (HTTP/1.1 update).
  
  307 Temporary Redirect -- The requested resource is available for a short time at a different URI, specified in the Location header field. This code was introduced along with 303 instead of 302 to avoid ambiguity. Introduced in RFC 2616 (HTTP/1.1 update).

• 400 Bad Request — The server detected a syntax error in the client's request. Introduced in HTTP/1.0.
  
  401 Unauthorized — Authentication is required to access the requested resource. The response header must contain the WWW-Authenticate field with a list of authentication conditions. The client can repeat the request, including the Authorization message header with the data required for authentication.
  
  402 Payment Required — Expected to be used in the future. Currently not used. This code is intended for paid user services, not for hosting companies. It is implied that this error will not be returned by the hosting provider in case of late payment for its services. Reserved since HTTP/1.1.
  
  403 Forbidden — The server understood the request, but it refuses to fulfill it due to restrictions on the client's access to the specified resource. If authentication by HTTP is required to access the resource, the server will return a 401 or 407 response when using a proxy. Otherwise, the restrictions were set by the server administrator or the web application developer and can be anything depending on the capabilities of the software used.
  
  In any case, the client should be informed of the reasons for refusing to process the request. The most likely reasons for the restriction may be an attempt to access system resources of the web server (for example, .htaccess or .htpasswd files) or files that were closed using configuration files, a requirement for authentication by non-HTTP means, for example, to access the content management system or a section for registered users, or the server is not satisfied with the client's IP address, for example, during blocking. Introduced in HTTP/1.0.
  
  404 Not Found - The most common error when using the Internet, the main reason is an error in writing the address of the Web page. The server understood the request, but did not find the corresponding resource at the specified URI. If the server knows that there was a document at this address, it is advisable for it to use the 410 code. The 404 response can be used instead of 403 if it is necessary to carefully hide certain resources from prying eyes. Introduced in HTTP/1.0.
  
  405 Method Not Allowed — The method specified by the client cannot be applied to the current resource. The server must specify the available methods in the Allow header in the response, separated by a comma. The server must return this error if the method is known to it, but it is not applicable to the resource specified in the request. If the specified method is not applicable to the entire server, then the client must return the code 501 (Not Implemented). Introduced in HTTP/1.1.
  
  406 Not Acceptable — The requested URI cannot match the characteristics passed in the header. If the method was not HEAD, then the server must return a list of acceptable characteristics for this resource. Introduced in HTTP/1.1.
  
  407 Proxy Authentication Required — The response is similar to the 401 code, except that authentication is performed for the proxy server. The mechanism is similar to identification on the original server. Introduced in HTTP/1.1.
  
  408 Request Timeout — The server has timed out waiting for the client to send a request. The client can repeat a similar request at any time. For example, this situation may occur when uploading a large file to the server using the POST or PUT method. At some point in the transfer, the data source stopped responding, for example, due to damage to the CD or loss of communication with another computer on the local network. While the client does not transmit anything, waiting for a response from it, the connection to the server is maintained.
  
  After some time, the server may close the connection on its side to allow other clients to make a request. This response is not returned when the client forcibly stops the transfer at the user's command or the connection is interrupted for some other reason, since it is no longer possible to send a response. Introduced in HTTP/1.1.
  
  409 Conflict — The request cannot be completed due to a conflicting access to the resource. This is possible, for example, when two clients try to change a resource using the PUT method. Introduced in HTTP/1.1.
  
  410 Gone — The server sends such a response if the resource was previously at the specified URL, but was deleted and is now unavailable. In this case, the server also does not know the location of an alternative document, for example, a copy). If the server suspects that the document may be restored in the near future, it is better to send the 404 code to the client. Introduced in HTTP/1.1.
  
  411 Length Required — For the specified resource, the client must specify Content-Length in the request header. Without specifying this field, you should not retry the request to the server at this URI. This response is natural for requests such as POST and PUT. For example, if files are uploaded at the specified URI, and the server has a limit on their size. Then it would be wiser to check the Content-Length header at the very beginning and immediately refuse to download, than to provoke a meaningless load by breaking the connection when the client actually sends too large a message. Introduced in HTTP/1.1.
  
  412 Precondition Failed — Returned if none of the conditional request header fields were satisfied. Introduced in HTTP/1.1.
  
  413 Request Entity Too Large — Returned if the server refuses to process the request due to the request body being too large. The server may close the connection to stop transmitting the request further. If the problem is temporary, it is recommended to include the Retry-After header in the server's response indicating the time after which a similar request can be repeated. Introduced in HTTP/1.1.
  
  414 Request-URI Too Large — The server cannot process the request because the specified URL is too long. This error can be caused, for example, when a client tries to pass long parameters via the GET method, rather than POST. Introduced in HTTP/1.1.
  
  415 Unsupported Media Type — For some reason, the server refuses to work with the specified media type for this method. Introduced in HTTP/1.1.
  
  416 Requested Range Not Satisfiable — The Range field of the request header specified a range beyond the end of the resource, and the If-Range field was missing. If the client sent a byte range, the server MAY return the actual size in the Content-Range field of the header. This response should not be used when sending multipart/byteranges. Introduced in RFC 2616 (HTTP/1.1 update).
  
  417 Expectation Failed — For some reason, the server could not satisfy the value of the Expect request header field. Introduced in RFC 2616 (HTTP/1.1 update).
  
  418 I'm a teapot — This code was introduced in 1998 as one of the traditional IETF April Fools' jokes in RFC 2324, Hyper Text Coffee Pot Control Protocol. It is not expected that this code will be supported by real servers.
  
  422 Unprocessable Entity — The server successfully accepted the request, can work with the specified data type, the XML document in the request body has the correct syntax, but there is some logical error that prevents the operation on the resource. Introduced in WebDAV.
  
  423 Locked — The target resource in the request is locked from being applied to the specified method. Introduced in WebDAV.
  
  424 Failed Dependency — The current request may depend on another operation being successfully completed. If it fails and the current request cannot be completed, the server will return this code. Introduced in WebDAV.
  
  425 Unordered Collection — Used in the WebDAV Advanced Collections Protocol extension. Sent if the client specified an item number in an unordered list, or requested multiple items in an order different from the server's.
  
  426 Upgrade Required — The server indicates to the client that a protocol upgrade is required. The response header must contain well-formed Upgrade and Connection fields. Introduced in RFC 2817 to enable the transition to TLS over HTTP.
  
  428 Precondition Required — The server indicates to the client that it should use conditional headers in the request, such as If-Match. Introduced in RFC 6585 draft.
  
  429 Too Many Requests — The client attempted to send too many requests in a short time, which may indicate, for example, a DoS attack. May be accompanied by a Retry-After header, indicating after how long the request may be retried. Introduced in RFC 6585 draft.
  
  431 Request Header Fields Too Large — The headers exceeded the allowed length. The server is not required to respond with this code; it may simply reset the connection instead. Introduced in draft RFC 6585.
  
  434 Requested host unavailable. — The requested address is not available.
  
  449 Retry With — Returned by the server if there is not enough information from the client to process the request. In this case, the Ms-Echo-Request field is placed in the response header. Introduced by Microsoft for WebDAV. Currently, at least is used by Microsoft Money.
  
  451 Unavailable For Legal Reasons — Access to the resource is closed for legal reasons, for example, at the request of government authorities or at the request of the copyright holder in the event of copyright infringement. Introduced in the IETF draft by Google, while the error code is a reference to Ray Bradbury's novel "Fahrenheit 451".
  
  456 Unrecoverable Error - Returned by the server if processing a request causes unrecoverable failures in the database tables. Introduced by Microsoft for WebDAV.
  
  499 Client Closed Request - Used by Nginx when the client closes the connection before receiving a response.

• 500 Internal Server Error — Any internal server error that does not fall within the scope of the other errors of the class. Introduced in HTTP/1.0.
  
  501 Not Implemented — The server does not support the capabilities required to process the request. A typical response for cases when the server does not understand the method specified in the request. If the server knows the method, but it is not applicable to this resource, then a 405 response should be returned. Introduced in HTTP/1.0.
  
  502 Bad Gateway — The server, acting as a gateway or proxy, received an invalid response message from an upstream server. Introduced in HTTP/1.0.
  
  503 Service Unavailable — The server is temporarily unable to process requests due to technical reasons (maintenance, overload, etc.). The server may specify a time in the Retry-After header after which the client is advised to repeat the request. Although it may seem obvious to immediately terminate the connection during overload, it may be more effective to set a large Retry-After field to reduce the frequency of redundant requests. Introduced in HTTP/1.0.
  
  504 Gateway Timeout — The server, acting as a gateway or proxy, did not wait for a response from the upstream server to complete the current request. Introduced in HTTP/1.1.
  
  505 HTTP Version Not Supported — The server does not support or refuses to support the version of the HTTP protocol specified in the request. Introduced in HTTP/1.1.
  
  506 Variant Also Negotiates — A misconfiguration causes the selected variant to point to itself, causing the binding process to fail. Experimental. Introduced in RFC 2295 to extend the HTTP protocol with Transparent Content Negotiation.
  
  507 Insufficient Storage — There is not enough storage to fulfill the current request. The problem may be temporary. Introduced in WebDAV.
  
  508 Loop Detected — The operation was cancelled because the server encountered an infinite loop while processing a request with no depth limit. Introduced in WebDAV.
  
  509 Bandwidth Limit Exceeded — Used when the web site exceeds its allocated traffic consumption limit. In this case, the site owner should contact their hosting provider. At the moment, this code is not described in any RFC and is used only by the "bw/limited" module, which is part of the cPanel hosting control panel, where it was introduced.
  
  510 Not Extended — The server does not have the extension that the client wants to use. The server can additionally transmit information about extensions available to it. Introduced in RFC 2774 to supplement the HTTP protocol with extension support.
  
  511 Network Authentication Required — This response is sent not by the server to which the request was intended, but by an intermediary server — for example, an ISP server — in cases where the client must first authenticate to the network, such as entering a password for a paid Internet access point. The response body is expected to return a Web authorization form or a redirect to it. Introduced in draft RFC 6585.

• The correct implementation of the secure method is the responsibility of the server application, the web server Apache, nginx, IIS itself will not be able to protect. This means that the application should not allow changing the server state by GET requests.

• The GET method requests a representation of a resource. Requests using this method can only retrieve data.

• The POST method is intended to send data to the server. Often causes a state change or some side effects on the server. The POST request is usually sent via an HTML form, and many other programs, scripts.

• The HEAD method requests a resource in the same way as the GET method, but without a response body.
  
  The HTTP HEAD method requests headers identical to those that would be returned if the specified resource were requested using the HTTP GET method. Such a request may be made before downloading a large resource, for example to save bandwidth.
  
  The response to the HEAD method must not contain a body. If it does not, it should be ignored. Even so, entity headers describing the contents of the body, such as Content-Length, must be included in the response. They do not apply to the body of the response to a HEAD request, which must be empty, but rather to the body of the response received for a similar request using the GET method.

• The PUT method replaces all current representations of a resource with the request data. Typically, PUT creates a new resource or replaces a representation of the target resource with the data provided in the request body.

• The DELETE method deletes the specified resource. Example of a DELETE header /file.html HTTP/1.1

• The CONNECT method establishes a "tunnel" to the server specified by the resource.

• The OPTIONS method is used to describe the connection parameters to a resource.

• The TRACE method calls the returned test message from the resource.

• The PATCH method is used to partially modify a resource.
  
  To indicate that the server supports PATCH, you can add this method to the Allow (en-US) or Access-Control-Allow-Methods (for CORS) response headers.

Recording A

Recording AAAA

Recording CNAME

Recording MX

Recording TXT

Recording SPF

Recording NS

Recording PTR

Recording SOA