Discover the most recent HTTP response codes

Three-digit HTTP response codes are numbers that the server issues in response to a client's browser request. These HTTP response codes give clients an immediate indication of how the server is operating and handling their requests. These codes additionally comprise some additional code used in typical HTTP applications as well as codes from other specifications, the IETF Request for Comments (RFC), and other specifications.

The Internet Assigned Numbers Authority (IANA) is the body that maintains the official registry of HTTP response codes. On HTTP's 3 digits, the first digit identifies the category of response codes, while the last two are assigned to a specific response type in a given category. There are five different types of HTTP response codes, and they are categorized based on how the server responds to the client:

1XX - Informational code: Indicates that the request has been received and understood, it is released temporarily while processing of the request continues. Credentials alert the client to wait for a final response. The message includes only the status line, and optional title fields, and is terminated with a blank line.

2XX - Success code: Indicates that the requested action by the client has been received, understood, and accepted. This means that the request made by the client was a request, the server completed what it was assigned and succeeded.

3XX - Redirection code: The client can take additional actions to complete the request. Usually, that extra action is to redirect the user to another URL. Many HTTP response codes in this category are used to redirect URLs.

4XX - Client error code: This category indicates that the request could not be fulfilled because of an error coming from the client. The request may contain incorrect syntax or lack of authorization,... The server should include an entity that explains the error situation (except when responding to a HEAD request) and indicates whether it was transient or forever.

5XX - Server error code: This category indicates that the server encountered an error or was unable to make a valid request. The server must include an entity containing an explanation of the error situation (except when responding to a HEAD request) and whether it is temporary or permanent.

Below are the most common HTTP response status codes for each category.

A. Informational code

100 Continue

This 100 code indicates that everything is fine and the browser can continue with the request or ignore it if it's done.

This is used to notify the client that the initial portion of the request has been received and has not yet been rejected by the server. The browser will then proceed by either sending the rest of the request or ignoring this response if the request has already been completed. The server must send the final response after the request is completed. A browser must first include Expect: 100-continue in the request header in its initial request, to receive the 100 Continue status code in the response before sending the content.

101 Switching Protocols

With code 101, the server is ready to convert the application protocol used in the connection upon request by the browser via the "Upgrade request" header. The server will also include in the response an “Upgrade to indicate the protocol it has switched to” response header.

The protocol can only be switched when it is more convenient to do, for example, to a newer version of HTTP than to an older version, and to a synchronous and real-time protocol when providing the resources it needs.

103 Initial Hints (Early Hints)

These HTTP response codes are used in conjunction with the link header to allow the user agent (e.g. browser) to start preloading the resource while the server is still preparing the response.

B. Success code (Success code)

200 OK

This status code indicates that the request was successful, it depends on the HTTP request method:

GET: The requested resource was passed in the response along with the message body. HEAD: Representative headers passed in the response without any message body. POST: A resource describing the result of the act passed in the response. TRACE: The response contains the request message when received by the server.

This category for a successful PUT or DELETE result is usually not 200 OK, but 204 “No Content” or 201 “Created” if the resource is uploaded for the first time. A 200 response is cacheable by default.

201 Created

This code indicates that the request was successful and resulted in the creation of a new resource. The server will have to create the resource before returning 201. The new resource is returned in the message body, and it can be located at the URI of the request or the body of the “Location” header.

202 Accepted

These HTTP response codes indicate that the request has been accepted for processing and that processing has not yet been completed or started. The request may or may not be fulfilled, as it may not be allowed when the actual processing takes place.

Status 202 is uncommitted. Its purpose is to allow the server to accept another request to another process (e.g. batch-oriented process) without requiring the user agent's connection to the server to persist until the complete process. This means, there is no way for HTTP to send a status code that then indicates the result of processing the request. However, the response will include an indicator of the current status of the request and a pointer to a status tracker or some estimate of when the user can expect the request to be fulfilled.

203 Non-Authoritative Information

203 indicates that the request was successful but the attached payload was modified by a proxy that converts from the origin server's 200 OK response. And the metadata information returned in the header is not a set that is certainly available from the origin server but is gathered from a local copy or a third-party replica. Response 203 is cacheable by default.

204 No Content

204 indicates that a request was successful, but no content should be returned, so the client does not need to navigate away from its current page. The 204 response includes nobody and is therefore always terminated with the first blank line after the header field.

This response is intended to allow input for actions to take place without causing changes to the browser's active page, although any new or updated information will be applied to the active page. of the browser. For example, when implementing save and continue editing functionality for a wiki page. In this case, a PUT request will be used to save the page and a 204 response will be sent indicating that the editor should not be replaced by another page. A 204 response is cacheable by default (the ETag header is included in such a response).

C. Redirection code

300 Multiple choices This code indicates that the request can have more than one response. The user agent or user should choose one of them. Unless it is a HEAD request, the response will include a list of resource characteristics and locations from which the user can select.

Depending on the format and browser capabilities, the most appropriate selection can be made automatically. If the server has a preferred choice of representation, it will include the specific URI for that representation in the field. Locations and browsers can use the Location field value for automatic redirects. Since there is no standardized way to select one of the responses, this response code is used very rarely. Response 300 is cacheable by default.

301 Moved Permanently

This status code indicates that the requested resource has been moved to the new permanent URI. The permanent URI is given by the “Location” field in the response. If the request method is HEAD, the response will contain a short hypertext note with hyperlinks to the new URIs. For non-GET or HEAD request methods, a 301 status code will not automatically redirect the request unless the user can confirm it, as this could change the conditions under which the request was submitted. out.

You should only use a 301 status code as a response to GET or HEAD methods because method changes are explicitly prohibited with this status, and use 308 Permanent Redirects for POST methods instead. 301 responses are cacheable by default.

302 Found

The HTTP response code 302 indicates that the requested resource has been temporarily moved to the URI. The temporary URI is given by the Location field in the response. If the request method is HEAD, the response will contain a short hypertext note with a hyperlink to the new URI(s). For request methods other than GET or HEAD, a 302 status code will not automatically redirect the request unless the user can confirm it, as this could change the conditions under which the request is received. given.

Code 302 should only be used as a response to GET or HEAD methods, as method changes are explicitly prohibited for this state, and a 307 Temporary Redirect should be used if the method is changed upon request. redirection is performed. In case you want the method used to be changed to GET, use 303 See Other instead. This is also useful when you want to give a response to a PUT method that is not an uploaded resource but a confirmation message such as “uploaded successfully”. A 302 response is cacheable if indicated by the Cache-Control or Expires header field.

303 See Other

303 indicates that the redirects do not link to newly uploaded resources but to a custom page (e.g. confirmation page or upload progress page). This status code is usually sent back as a result of a PUT or POST. The method used to display this redirected page is always GET.

304 Not Modified

This code indicates that there is no need to retransmit the requested resources. It is an implicit redirect to a cached resource. This happens when the request method is safe, such as GET or HEAD, or when the request is conditional and uses an If-None-Match or If-Modified-Since header. A response like the equivalent 200 OK will include the Cache-Control, Content-Location, Date, ETag, Expires, and Vary headers.

307 Temporary Redirect

Code 307 indicates that the requested resource has been temporarily moved to the URI. The temporary URI is given by the Location field in the response. The only difference between 307 and 302 Found is that 307 ensures that the method and content will not be changed when the redirect request is made. For GET requests, the 302 and 307 behavior is identical. Behavior with non-GET and 302 Found methods is then unpredictable on the website, while behavior with 307 is predictable.

In case the user wants the method used to be changed to GET, use 303 See Other instead. This is also useful when you want to give the PUT method an answer that is not an uploaded resource but a confirmation message (like “you uploaded successfully”).

308 Permanent Redirect

These HTTP response codes indicate that the requested resource has been passed to the URI. The permanent URI is given by the Location field in the response. The request method and body will not be changed, while the 301 can sometimes incorrectly be changed to the GET method.

D. Client error code

400 Bad Request

Code 400 indicates that the server was unable to process the request due to a client-side error, such as malformed request syntax, invalid request message frames, or deceptive request routing. Customers are advised not to repeat the request unless modifications are made.

401 Unauthorized

These HTTP response codes indicate that the request has not been applied because it lacks valid credentials for the target resource. This status is sent with a WWW-Authenticate header that contains information on how to properly grant permissions. With this status code, the request can be repeated by including authentication to access the target resource. This status is similar to 403, but in this case, authentication is possible.

402 Payment Required

The 402 code is a non-standard client error and is reserved for future use. It was created to enable digital cash or payment systems and will indicate that the request cannot be processed until the customer has made the payment. However, no standard usage convention exists and different entities use it in different contexts.

403 Forbidden (Forbidden)

403 indicates that the server understood the request but rejected it. This status is similar to 401 Unauthorized, but in this case, re-authentication will make no difference, so no need to repeat the request. Access is permanently banned and tied to application logic, such as insufficient permissions on resources. For any request method except HEAD, if the server wants the rejection reason to be available to the client, then 403 can be used. However, if the server does not want to provide this information, then 404 Not Found can be used instead.

404 Not Found

The 404 code indicates that the server cannot find anything that matches the Request URI. Links that lead to a 404 page are often referred to as broken links or dead links. There is no indication as to whether the condition is temporary or permanent. But if the server knows that the resource is permanently deleted, then the 410 Gone status should be used instead of the 404 status. This status code is also commonly used when the server does not want to reveal exactly why. the request is denied or when no other response applies. The 404 response is cacheable by default.

405 Method Not Allowed

HTTP response codes 405 indicates that the request method is known to the server but not supported by the target resource. The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The server must generate an Allow header field that contains a list of supported methods for the requested resource. The 405 response is cacheable by default.

480 Request Timeout

With 480, the code indicates that the server wants to shut down this unused connection because the request has exceeded the time the server is about to wait. The client can repeat the request without modification at any time later. The server will send a "close" header field in the response because 408 implies that the server has decided to close the connection instead of continuing to wait.

409 Conflict (Conflict)

409 indicates that a request could not be completed due to a conflict with the current state of the target resource. This code is allowed in situations where the client can resolve the conflict and resend the request. Therefore, the responding agency should provide enough information for the client to recognize the source of the conflict.

This is most likely to happen in response to a PUT request. For example, you may receive a 409 response when uploading a file that is older than the file already on the server, resulting in a version control conflict. In this case, the response should contain a list of differences between the two versions in a format determined by the Content-Type of the response.

**410 Gone **

This status code indicates that access to the target resource is no longer permanent at the origin server and that no forwarding address is known. If the server owner doesn't know whether the condition is temporary or permanent, 404 should be used instead.

The 410 response is intended primarily to assist with website maintenance by notifying customers that a resource is intentionally unavailable and that the server owner wishes that remote links to that resource be removed. Such an event usually occurs for limited-time promotional services and for resources belonging to individuals who are no longer active at the server's site. 410 response is cacheable by default.

414 URI too long

414 indicates that the server refused to process the request because the Request URI provided by the client was longer than the server was willing to understand.

There are several conditions when this can happen: When the client has incorrectly converted a POST request to a GET request with long query information,  when the client has switched to a redirect loop (for example the redirected URI prefix points to a suffix of its own), or when the server is being attacked by a client attempting to exploit potential security vulnerabilities. The 414 response is cacheable by default.

415 Unsupported Media Type

415 indicates that the server refused to accept the request because the payload format is in an unsupported format. Formatting issues can be caused by the Content-Type or Content-Encoding specified in the request, or by checking the data directly.

429 Too Many Requests

These HTTP response codes indicate that the user has sent too many requests in a certain period (rate limit). Response representations may include details explaining the condition and a “Try again later” header indicating how long to wait before issuing a new request. However, when a server is under attack or is only receiving a very large number of requests from one party, responding to each request with a 429 status code consumes resources, so it may be preferable. if just disconnect or take other steps.

E. Server error code

500 Internal Server Error (Internal Server Error)

Error 500 indicates that the server encountered an unexpected condition that prevented the server from making the request. This error response is often used as a catch-all generic response indicating that the server could not find a better 5xx status code to respond to. Sometimes, server administrators record error responses like a 500 status code with more details about the request to prevent the error from happening again in the future. ** 501 Not Implemented**

This status code means that the server does not support the functionality required to make the request. This status can also send a “Retry” header after letting the customer know when to check back to see if the functionality is supported. The 501 code is not something that can be fixed but requires the fix of the web server you are trying to access.

This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resources. The only methods the server is required to support are GET and HEAD and should therefore not return a 501. If the server recognizes the method but intentionally does not support it, the appropriate response is the method. 405. The 501 response is cacheable by default unless the caching headers instruct otherwise.

502 Bad Gateway

This status code indicates that the server while acting as a gateway or proxy, received an invalid response from the source server when it attempted to make the request. The 502 code is not something that can be fixed but requires a fix by the web server or proxy you are trying to access.

503 Service Unavailable

Error 503 indicates that the server is currently unavailable and not ready to process any requests due to temporary server overload or maintenance. This reaction is used as a temporary measure, which is expected to subside after a while. Along with this response, the “Retry” header should contain an estimated time to restore service, and a user-friendly page explaining the problem should also be included. If there is no “Retry” request, the client should treat the response as it would for a 500 response.

504 Gateway Timeout

This status code indicates that the server while acting as a gateway or proxy, did not receive a timely response from the source server specified by the URI (e.g. HTTP, FTP, LDAP) or some machine from another backend server (e.g. DNS) when trying to make a request. A 504 code is usually not fixable but requires a fix by the web server or proxy you're trying to access.

The most common categories of HTTP response codes as of right now are listed above. Regardless of how HTTP codes are employed, consistency is necessary for the client to comprehend and act upon the server's request. Following this post, I hope you have a thorough understanding of HTTP response codes.

If you have any questions about HTTP response codes or would want to try out VNIS's smart website security solution, kindly fill out the form below or give them a call at (028) 7306 8789.