Share This:

Server response codes. Description of HTTP header codes.
HTTP status code - the status code is part of the first line of the server response. It is a 3 Arabic numeral integer. The first digit indicates the class of the condition. 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. Example:

403 Access allowed only for registered users

The client learns from the response code about the results of his request and determines what actions he should take next. The set of status codes is a standard, and they are all described in the corresponding RFCs. The introduction of new codes should be made only after consultation with the IETF. The client may not know all the status codes, but it is the responsibility of the client to respond according to the class of the code.

Currently, there are five classes of status codes:

1xx: Informational - the request has been received and understood, but processing continues.
2xx: Success - The request was successfully received, understood and processed.
3xx: Redirection - further actions must be taken to complete the request.
4xx: Client Error - the request has bad syntax or could not be completed.
5xx: Server Error - The server is unable to fulfill a valid request.
Below are the response codes from the IANA Status Code Registry.

1xx: Informational

This class contains codes that inform about the transmission process. In HTTP / 1.0, messages with such codes should be ignored. In HTTP / 1.1, the client must be prepared to accept this message class as a normal response, but nothing needs to be sent to the server. The messages from the server themselves contain only the start line of the response and, if required, a few response-specific header fields. Proxy servers should send such messages further from the server to the client.

100 Continue The server is satisfied with the initial details of the request. The client can continue to send headers.

101 Switching Protocols (Russian. Switching protocols) The server offers to switch to a protocol that is more suitable for the specified resource. The server must indicate the list of proposed protocols in the Update header field. If the client is interested in this, then he sends a new request indicating a different protocol.

102 Processing The request was accepted, but it will take a long time to process. Used by the server to prevent the client from dropping the connection due to timeout. Upon receipt of such a response, the client must reset the timer and wait for the next command in the normal mode.

2xx: Success

Messages of this class inform about cases of successful acceptance and processing of a client's request. Depending on the status, the server can also transmit the headers and body of the message.

200 OK Successful request. If the client has requested any data, then they are in the header and / or body of the message.

201 Created A new resource was created as a result of the successful execution of the request. The server should indicate its location in the Location header. The server is also recommended to indicate in the header the characteristics of the created resource (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, then it is better to use the 202 response.

202 Accepted The request has been accepted for processing, but processing has not been completed. The client does not have to wait for the final transmission of the message, as a very long process can be started.

203 Non-Authoritative Information Similar to answer 200, but in this case the transmitted information was not taken from the primary source (backup copy, another server, etc.) and therefore may not be up-to-date.

204 No Content The server successfully processed the request, but only headers without a message body were sent in the response. The client does not need to update the content of the document, but can apply the received metadata to it.

205 Reset Content The server obliges the client to ask for the data entered by the user. At the same time, the server does not transmit the message body, and it is not necessary to update the document.

206 Partial Content The server successfully completed the client's request, but only transferred part of the document. The server can send such a response if there is a Content-Range field in the client's request header. Particular attention should be paid to caching when working with such responses.

207 Multi-Status (Russian. 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 a single multistatus object. It is not recommended to place statuses from the 1xx series in this object because of its meaninglessness and redundancy.

226 IM Used The A-IM header from the client was successfully received and

the server returns the content based on the specified parameters.

3xx: Redirection

The 3xx class status codes tell the client to make the next request to a different URI in order to successfully complete the operation. In most cases, the new address is specified in the Location header field. In this case, the client should, as a rule, make an automatic transition (jargon redirect).

Note that when accessing the following resource, you can get a response from the same code class. It may even result in a long chain of redirects, which, if done automatically, would create an excessive load on the equipment. Therefore, the developers of the HTTP protocol strongly recommend that after the second row of such a response, be sure to request confirmation of the redirect from the user (it was previously recommended after the 5th). It is the responsibility of the client to monitor this, since the current server can redirect the client to a resource on another server. The client must also prevent it from getting caught in round-robin redirects.

300 Multiple Choices According to the specified URI, there are several options for providing a resource by MIME type, language or other characteristics. The server sends a list of alternatives with a message, giving the opportunity to make a choice to the client or user.

301 Moved Permanently The requested document has been finally moved to the new URI specified in the Location field of the header. For requests other than the HEAD method, the server must transmit a hypertext explanation in the body of the message. When using all methods except GET and POST, you should first notify the user about the link change. Do not forget that some agents mistakenly change the POST method to GET after switching to another address.

302 Found The requested document has been temporarily moved to a different URI specified in the header in the Location field. For all methods except HEAD, the server must transmit a hypertext explanation in the body. When using all methods other than GET and POST, you must first notify the user about the URI change. When accessing the next resource, the POST method should be changed to GET as some agents do.

303 See Other The document at the requested URI must be requested by the address in the Location header field using the GET method, even though the first was requested by the POST method. If a non-HEAD method is used, the server SHOULD include a short hypertext description in the message body.

304 Not Modified The server returns this code if the client requested a document using the GET method, used the Date field in the header, and the document has not changed since the specified moment. In this case, the server message should not contain a body.

305 Use Proxy The request to the requested resource must be made through a proxy server whose URI is specified in the Location header field. This response code can only be used by native HTTP servers (not proxies).

306 (Reserved) Used before. Currently reserved.

307 Temporary Redirect The requested resource is available for a short time only by a different URI (specified in the Location header field). If a non-HEAD method was sent, the server SHOULD include a short hypertext description in the message body. When using all methods except GET and POST, you should first notify the user about a temporary link change.

4xx: Client Error

The 4xx class of codes is intended to indicate client-side errors. When using all methods except HEAD, the server must return a hypertext explanation to the user in the body of the message.

400 Bad Request The request was not understood by the server due to a syntax error. The client should re-access the resource with the modified request.

401 Unauthorized The request requires user identification. The client should ask the user for a name and password and pass them in the WWW-Authenticate header records in the next request. In case of entering erroneous data, the server will return the same status.

402 Payment Required (Reserved) To be used in the future. Currently not used.

403 Forbidden The server understood the request, but it refuses to fulfill it due to some access restrictions. Authentication via HTTP won't help here. Most likely, the server needs to authenticate in a different way, make a request with certain parameters, or satisfy some conditions.

404 Not Found The server understood the request, but did not find a matching resource at the specified URI. If the server knows that there was a document at this address, then it is desirable to use the 410 code instead. This code can be used instead of 403 if you need to carefully hide certain resources from prying eyes.

405 Method Not Allowed

f supported) The client-specified method cannot be applied to the resource. The server must also send the Allow field with a list of available methods in the response header.

406 Not Acceptable The requested URI could not satisfy the specifications in the header. If the method was not HEAD, then the server should return a list of acceptable characteristics for this resource.

407 Proxy Authentication Required The answer is similar to the 401 code, except that the authentication is done for the proxy server. The mechanism is similar to identification on a regular server.

408 Request Timeout The server has timed out for a transmission from the client. The client can repeat the request similar to the previous one at any time.

409 Conflict The request could not be completed due to a conflicting call to the resource. This is possible, for example, when two clients try to modify a resource using the PUT method.

410 Gone (Russian. Deleted) This response is sent by the server when the resource was previously at the specified URI, but was deleted and is now unavailable. In this case, the server does not know the location of the alternative document (for example, a copy). If the server has a suspicion that the document can be restored in the near future, then it is better to send the 404 code to the client.

411 Length Required For the specified resource, the client must specify the Content-Length in the request header. Without specifying this field, you should not make a second attempt to request the server using this URI.

412 Precondition Failed Returned if none of the conditional fields in the request header were met.

413 Request Entity Too Large (Russian. The requested data is too large) Returned if the server, for some reason, cannot transfer the requested amount of information. If the problem is temporary, the server can indicate in the Retry-After field the time after which a similar request can be repeated.

414 Request-URI Too Long The server cannot process the request because the specified URI is too long. Such an error can be triggered, for example, when the client tries to pass long parameters through the GET method rather than POST.

415 Unsupported Media Type For some reason, the server refuses to work with the specified data type with this method.

416 Requested Range Not Satisfiable The Range field of the request header specified a range outside of the resource and the If-Range field is missing. If the client has passed a byte range, then the server can return the actual size in the Content-Range header field. This answer should not be used when passing multipart / byteranges.

417 Expectation Failed For some reason the server cannot satisfy the value of the Expect field in the request header.

422 Unprocessable Entity The server has 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 kind of logical error due to which it is impossible to perform an operation on the resource.

423 Locked The target resource from the request is locked from the specified method being applied to it.

424 Failed Dependency The implementation of the current request may depend on the success of another operation. If it has not been completed and because of this it is impossible to fulfill the current request, the server will return code 424.

426 Upgrade Required The server instructs the client to upgrade the protocol. The response header must contain well-formed Upgrade and Connection fields.

5xx: Server Error

5xx codes are allocated for cases of unsuccessful operation due to the fault of the server. For all situations other than using the HEAD method, the server must include an explanation in the message body that the client will display to the user.

500 Internal Server Error Any internal server error that does not fall within the scope of other 5xx class errors.

501 Not Implemented The server does not support the capabilities required to process the request. Typical response for cases when the server does not understand the method specified in the request.

502 Bad Gateway The server acting as a gateway or proxy received a message indicating that the interim operation was unsuccessful.

503 Service Unavailable The server is temporarily unable to process requests for technical reasons (maintenance, overload, etc.). In the Retry-After field of the header, the server can specify the time after which the client is recommended to repeat the request. While it is obvious to drop the connection immediately during congestion, it may be more efficient to set a large Retry-After value to reduce the frequency of redundant requests.

504 Gateway Timeout The server as a gateway or proxy did not wait for

Veta from the upstream server to complete the current request.

505 HTTP Version Not Supported The server does not support or refuses to support the version of the HTTP protocol specified in the request.

506 Variant Also Negotiates (Experimental) As a result of an erroneous configuration, the selected option points to itself and the binding process is interrupted.

507 Insufficient Storage There is not enough space to complete the current request. The problem may be temporary.

510 Not Extended The server is missing an extension that the client intends to use. The server can additionally transmit information about the extensions available to it.

^ Top