Demystifying HTTP Status Codes: A Comprehensive Guide for Developers(from 100 to 599)

Informational Status Codes (100 level)

HTTP 100-level status codes, also known as informational status codes, are used to provide preliminary information about a request and are generally not encountered in everyday web development. These codes are meant to communicate the status of the request even before it's fully processed. Let's explore these codes in more detail:

100 :

The 100 Continue status code is used to indicate that the initial part of a request has been received and understood by the server. It serves as a signal to the client that it can proceed with sending the remaining parts of the request. This is particularly relevant when a client is sending a large request body, and the server wants to acknowledge receipt and encourage the client to continue sending the data.

Example use case:

• When a client sends an HTTP POST request with a large file upload, the server might respond with a 100 Continue to signal that it's ready to receive the file data.

101 :

The 101 Switching Protocols status code indicates that the server is changing the protocol being used by the client. It is typically used in the context of WebSocket upgrades or other protocol switches. After receiving this status code, the client should follow the protocol specified by the server.

Example use case:

• During an HTTP request, the client might request an upgrade to WebSocket communication. The server responds with 101 Switching Protocols to indicate the switch to WebSocket communication.

102 :

The 102 Processing status code is used to inform the client that the server has received the request and is in the process of performing it. This status code is generally used in scenarios where the server requires more time to complete the request and wants to prevent the client from timing out.

Example use case:

• When a client sends a request that triggers a long-running server operation, such as generating a complex report, the server may respond with a 102 Processing status code while it works on the request.

103 :

The 103 Early Hints status code is a relatively new addition to HTTP and is used to provide hints to the client about possible responses before the final response is available. It can be used to push resources to the client that are likely to be needed based on the initial request.

Example use case:

• A server might send a 103 Early Hints response to instruct the client to preload certain CSS and JavaScript files that are commonly required for rendering a specific web page.

In practice, you may not encounter these 100-level status codes frequently, as they are more relevant in specific scenarios that involve advanced HTTP features or optimizations. They are designed to facilitate communication between the client and server when special handling is needed, often in high-performance or asynchronous use cases.

Successful Status Codes (200 level)

200 :

The 200 OK status code is the most fundamental and commonly encountered in HTTP. It simply indicates that the request has been successfully processed, and the server is returning the requested information. However, it provides limited information about the nature of the response. Developers often use it as a fallback status code when there isn't a more specific code applicable.

Example use cases:

• When a client requests a web page, and the server successfully returns the HTML content.

• After a successful GET request for retrieving data from a RESTful API.

201 :

The 201 Created status code signifies that a resource has been successfully created as a result of the request. It is commonly used in response to POST requests, where the client is sending data to the server to create a new resource. When the server successfully creates the resource, it should include a Location header in the response pointing to the newly created resource's URL.

Example use cases:

• After a successful POST request to create a new user account.

• When adding a new item to an online store's catalog.

202 :

The 202 Accepted status code indicates that the request has been received and accepted by the server, but the server has not yet completed the requested action. It's often used when the action takes a significant amount of time to process, and the server needs more time before it can provide a definitive response. The client may need to check back later to see if the action has been completed.

Example use cases:

• When a client submits a time-consuming task like generating a large report, and the server queues it for processing.

• In scenarios where a background job is initiated but hasn't finished yet.

204 :

The 204 No Content status code signifies a successful request where the server has processed the request but is intentionally not sending any data in the response body. It's typically used with HTTP methods like DELETE, where the client requests the removal of a resource, and the server successfully performs the deletion, but there's no data to return.

Example use cases:

• After a successful DELETE request to delete a user account.

• When removing an item from a shopping cart in an e-commerce application.

Understanding these 200-level status codes is crucial for API developers, as they indicate the successful execution of various types of requests, helping both clients and servers communicate effectively.

Redirection Status Codes (300 level)

HTTP 300-level status codes are used for redirection. They inform the client that the resource they requested is available at a different location, and the client should follow the provided redirection instructions to access the resource. Let's explore these redirection status codes in more detail:

300 :

The 300 Multiple Choices status code indicates that the requested resource has multiple representations available, and the server is unable to choose one. The server provides a list of alternative resources, and the client can make the selection. This code is not commonly used in practice.

Example use case:

• If a web page is available in multiple languages, the server might respond with a 300 Multiple Choices status code and provide links to the versions in different languages.

301 :

The 301 Moved Permanently status code informs the client that the requested resource has been permanently moved to a new URL. The client should automatically update its bookmarks or links to use the new URL. Search engines also consider this redirection, updating their indexes accordingly.

Example use case:

• When a website restructures its URLs, the server might respond with a 301 status code, ensuring that old URLs automatically redirect to their new equivalents.

302 :

The 302 Found status code is used to indicate a temporary redirection. It informs the client that the requested resource is temporarily available at a different URL. Unlike a 301 redirect, search engines do not update their indexes with the new URL.

Example use cases:

• A website might use a 302 redirect to send users to a different page temporarily, perhaps for A/B testing or during a temporary maintenance period.

• Temporary promotional pages or holiday-themed pages can also use 302 redirects.

303 :

The 303 See Other status code informs the client that the response to the request can be found at a different URL. It's often used in combination with the HTTP POST method to indicate that the client should perform a GET request to retrieve the resource from the new location.

Example use case:

• After a successful form submission via POST, the server might respond with a 303 status code, instructing the client to perform a GET request to view the confirmation page.

304 :

The 304 Not Modified status code is used for caching purposes. It indicates that the requested resource has not been modified since the client's last request. This is typically used in conjunction with conditional GET requests, where the client includes information about its cached version of the resource.

Example use case:

• When a client makes a GET request for a resource that hasn't changed since the last request, the server responds with a 304 status code, saving bandwidth by not sending the resource again.

307 :

The 307 Temporary Redirect status code is similar to 302 Found but is explicitly intended to preserve the original HTTP method (e.g., GET or POST) when redirecting. It instructs the client to make the same request to the new URL.

Example use case:

• If a client sends a POST request to a URL, and the server needs to temporarily redirect the client, it can respond with a 307 status code to ensure that the client reissues the POST request to the new location.

308 :

The 308 Permanent Redirect status code is similar to 301 Moved Permanently but, like the 307 status code, preserves the original HTTP method. It indicates that the requested resource has been permanently moved, and the client should continue to use the same HTTP method for subsequent requests.

Example use case:

• When a website changes its domain name permanently, it can respond with a 308 status code to ensure that clients continue to use the same HTTP method (e.g., POST or PUT) when accessing resources at the new domain.

Understanding these 300-level status codes is important for web developers, as they allow for efficient handling of resource movements and changes in URLs, ensuring that clients can access the correct content seamlessly.

Client Error Status Codes (400 level)

HTTP 400-level status codes are used to indicate that there is an issue with the client's request. These status codes signal errors caused by the client, typically due to malformed or invalid requests. Understanding these codes is essential for diagnosing and handling client-side issues effectively. Let's explore these 400 status codes in more detail:

400:

The 400 Bad Request status code is a general-purpose error indicating that the server cannot understand or process the client's request due to issues like invalid syntax, missing parameters, or invalid data. It's the default status code for client-related errors.

Example use cases:

• Missing or incorrectly formatted request parameters.

• Invalid JSON data in the request body.

• Requesting an unsupported HTTP method for a resource.

401 :

The 401 Unauthorized status code indicates that the client's request is missing or has invalid authentication credentials. This status code is often associated with authentication challenges, prompting the client to provide valid credentials.

Example use cases:

• Accessing a protected resource without providing authentication (e.g., missing API key or invalid username/password).

• Expired or revoked authentication tokens.

402 :

The 402 Payment Required status code is reserved for potential future use and is not commonly used in practice.

403 :

The 403 Forbidden status code signifies that the client has provided valid authentication credentials, but those credentials lack the necessary permissions to access the requested resource. It's used when the server understands the client's request but refuses to fulfill it due to permissions or access restrictions.

Example use cases:

• A regular user trying to access an admin-only section of a website.

• An authenticated user attempting to perform an action reserved for administrators.

404 :

The 404 Not Found status code is one of the most recognizable HTTP status codes. It indicates that the requested resource does not exist on the server or is not accessible at the provided URL. It's often used when a client attempts to access a non-existent webpage or resource.

Example use cases:

• Accessing a URL that has been removed or never existed.

• Requesting an item from a database that is not present.

405 :

The 405 Method Not Allowed status code indicates that the client has used an HTTP method that is not supported for the requested resource. It tells the client which HTTP methods are allowed for the resource.

Example use cases:

• Attempting to use a POST request on a resource that only supports GET requests.

• Using an HTTP method that the server does not permit for the given resource.

406 :

The 406 Not Acceptable status code is used when the server cannot provide a response that meets the criteria specified in the client's request headers, typically in terms of content type or language.

Example use cases:

• Requesting a specific content type (e.g., JSON) that the server cannot provide.

• Specifying a language preference for content, but the server does not support that language.

407:

The 407 Proxy Authentication Required status code is similar to 401 Unauthorized but is specifically used in cases where the client must first authenticate itself to a proxy server before accessing the requested resource.

Example use cases:

• A client attempting to access a website through a proxy server without providing valid proxy authentication credentials.

408 :

The 408 Request Timeout status code indicates that the client's request took too long to complete, and the server terminated the connection. This can occur when the server has a timeout limit for processing requests.

Example use cases:

• Sending a request to a server that has a short timeout for client connections.

• Slow network connections cause a request to exceed the server's timeout.

409:

The 409 Conflict status code is used to indicate that the client's request conflicts with the current state of the server. It often arises in scenarios where concurrent updates or conflicting actions occur.

Example use cases:

• Concurrent attempts to modify the same resource, such as a file, causing a conflict.

• A client trying to update a resource that has been modified by another client in the meantime.

410 :

The 410 Gone status code signifies that the requested resource was once available but has been intentionally removed or is no longer accessible. Unlike 404 Not Found, 410 indicates that the resource is gone and will not return.

Example use cases:

• Decommissioning a web page or service and signaling to clients that it will not return.

411 :

The 411 Length Required status code is used when the server requires the client to specify the Content-Length header in its request. This header indicates the size of the request body.

Example use cases:

• Sending a POST request without specifying the Content-Length header, which is necessary for the server to process the request.

412 :

The 412 Precondition Failed status code is used when the server's conditions specified in the request headers are not met. This often relates to conditional requests using headers like If-Match or If-None-Match.

Example use cases:

• Using the If-None-Match header to request a resource, but the resource has changed since the client's last request.

413 :

The 413 Payload Too Large status code is returned when the server rejects a client's request due to the size of the request payload exceeding server-defined limits.

Example use cases:

• Uploading a file or data that exceeds the server's configured request size limit.

414 :

The 414 URI Too Long status code is used when the client's request URI (Uniform Resource Identifier) is too long for the server to process. This can happen when URLs are excessively lengthy.

Example use cases:

• Sending a URL with numerous query parameters that exceed the server's URI length limit.

415 :

The 415 Unsupported Media Type status code indicates that the server cannot process the request because the client has provided a media type (content type) in the request headers that the server does not support or understand.

Example use cases:

• Sending data with a content type that the server does not recognize or support.

416:

The 416 Range Not Satisfiable status code is used in scenarios where the client has requested a specific range of data from a resource (using the Range header), but that range is not available or valid.

Example use cases:

• Requesting a byte range of a file that exceeds the available range.

417 :

The 417 Expectation Failed status code is used when the server cannot meet the expectations specified by the client in the Expect request header. This header is typically used for conditional requests.

Example use cases:

• A client sets an expectation in the Expect header that the server cannot fulfill.

418 :

The 418 I'm a teapot status code is not meant to be taken seriously and is part of an April Fools joke. It's used to add humor to the HTTP protocol and should not be used in real-world applications.

421 :

The 421 Misdirected Request status code is used when a request is sent to a server that is not properly configured to handle it. This can occur in scenarios where a client expects a secure connection but

is directed to an insecure server or vice versa.

Example use cases:

• A client attempts to access an HTTPS resource but is redirected to an HTTP server that does not support HTTPS.

422 :

The 422 Unprocessable Entity status code is used to indicate that the server understands the client's request, but the request is semantically incorrect or contains validation errors. It is commonly used in the context of RESTful APIs when the request data cannot be processed.

Example use cases:

• Submitting data to an API where the data structure is correct, but the values provided are invalid or do not meet validation criteria.

423:

The 423 Locked status code is used to indicate that the requested resource is locked and cannot be accessed or modified at the moment. This is often used in distributed systems to handle resource concurrency.

Example use cases:

• Trying to modify a resource that is currently locked by another process.

424:

The 424 Failed Dependency status code is used when the request cannot be completed because it depends on the successful execution of another request. It's often used in scenarios where multiple requests are related, and one request's failure affects another.

Example use cases:

• A batch of requests where one request relies on the successful outcome of a previous request.

425:

The 425 Too Early status code is used to indicate that the client should retry the request at a later time. It is often used in the context of early data in TLS (Transport Layer Security) connections.

Example use cases:

• Requesting data too early in the establishment of a secure connection.

426 :

The 426 Upgrade Required status code is used when the client's request cannot be processed because it requires an upgrade to a different protocol. This is often used to prompt clients to switch to a more secure or advanced protocol.

Example use cases:

• Encouraging clients to upgrade to a newer version of a protocol or to switch to a more secure communication method.

428 :

The 428 Precondition Required status code is used to indicate that the client must include conditional headers (such as If-Match or If-None-Match) in its request to ensure that the server processes it correctly.

Example use cases:

• Submitting a request that requires a conditional header for validation or version control.

429 :

The 429 Too Many Requests status code is used to inform the client that it has exceeded rate limits or request quotas. This is often used to prevent abuse or overuse of resources.

Example use cases:

• Restricting the number of API requests a client can make within a certain time frame.

431 :

The 431 Request Header Fields Too Large status code is used when the headers in the client's request are too large for the server to process. This can occur when a client includes an excessive number of headers or when individual headers are too long.

Example use cases:

• Sending a request with an excessive number of cookies or headers.

451 :

The 451 Unavailable For Legal Reasons status code is used when a server is legally required to deny access to a resource, such as due to censorship or legal restrictions.

Example use cases:

• Blocking access to certain content due to legal requirements or court orders.

444 :

The 444 No Response status code is non-standard and is often used by NGINX to indicate that the server has not sent a response to the client.

450 :

The 450 Blocked by Windows Parental Controls status code is non-standard and indicates that access to the requested resource is blocked by parental control settings in Windows.

498 :

The 498 Invalid Token status code is non-standard and is used by some web services to indicate that the provided authentication token is invalid.

499 :

The 499 Token Required status code is non-standard and is used by some web services to indicate that an authentication token is required for the request.

These 400-level status codes help developers identify and address client-related issues when making HTTP requests. By understanding these codes, developers can diagnose problems more effectively and provide appropriate feedback to users and clients.

Server Error Status Codes (500 level)

HTTP 500-level status codes are used to indicate that there is an issue with the server that prevented it from fulfilling the client's request. These status codes signal errors on the server side, and they typically indicate that something went wrong with the server's processing of the request. Let's explore these 500 status codes in more detail:

500 :

The 500 Internal Server Error status code is one of the most generic server error responses. It indicates that an unexpected condition occurred on the server, and the server was unable to fulfill the request. This status code doesn't provide specific details about the nature of the error.

Example use cases:

• Server misconfigurations.

• Software bugs or exceptions that weren't handled properly.

• Database errors that prevent the server from retrieving or storing data.

501:

The 501 Not Implemented status code indicates that the server does not support or has not implemented the functionality required to fulfill the client's request. This response is typically used when the server doesn't recognize the HTTP method used in the request.

Example use cases:

• A client sends a request with an HTTP method that the server does not support.

• A server is under development, and certain features are not yet implemented.

502:

The 502 Bad Gateway status code is used when a server acting as a gateway or proxy encounters an error while forwarding the client's request to another server. It essentially means that the server acting as a gateway received an invalid response from an upstream server.

Example use cases:

• A reverse proxy server receives an invalid response from the application server it forwards requests to.

• An intermediary server acting as a load balancer encounters an issue when routing requests to backend servers.

503 :

The 503 Service Unavailable status code indicates that the server is temporarily unable to handle the request due to being overloaded or undergoing maintenance. This status code is often used when a server is intentionally taken offline for maintenance.

Example use cases:

• Server maintenance or updates.

• Excessive traffic causing server overload.

• Temporary unavailability of resources or services.

504:

The 504 Gateway Timeout status code is similar to 502 Bad Gateway, but it specifically indicates that the server acting as a gateway or proxy did not receive a timely response from an upstream server. This typically occurs when the upstream server is slow to respond or has timed out.

Example use cases:

• An intermediary server forwards a request to an application server that is slow to respond or has crashed.

• Network issues causing delays in communication between servers.

505 :

The 505 HTTP Version Not Supported status code is used when the client's request specifies an HTTP protocol version that is not supported by the server. This can happen when a client uses an outdated or unsupported HTTP version.

Example use cases:

• A client sends an HTTP/2 request to a server that only supports HTTP/1.1.

• A server that has not been updated to support newer HTTP versions.

506 :

The 506 Variant Also Negotiates status code is used when the server has an internal configuration error related to content negotiation. Content negotiation allows the server to select the most appropriate representation of a resource based on the client's preferences.

Example use cases:

• Issues with the server's content negotiation configuration.

• Misconfigured server settings for handling multiple content variants.

507 :

The 507 Insufficient Storage status code is used to indicate that the server is unable to store the representation needed to complete the request. This can occur when a server runs out of storage space.

Example use cases:

• Attempting to upload a file to a server that has exceeded its storage capacity.

• Insufficient storage space to handle database transactions or data storage.

508 :

The 508 Loop Detected status code is used when the server detects an infinite loop while processing the request. This status code is typically used for debugging purposes or to prevent server resources from being consumed by a looping request.

Example use cases:

• A server detects a circular reference or loop in a request that could lead to infinite processing.

• Implementations of recursive algorithms that need to prevent infinite recursion.

510:

The 510 Not Extended status code indicates that further extensions to the request are required for the server to fulfill it. This status code is typically used when a server receives an extended request that it doesn't fully understand without additional information.

Example use cases:

• A client sends a request with custom extensions or headers, and the server requires additional information or headers to process it correctly.

511 :

The 511 Network Authentication Required status code is used to indicate that network authentication is required before the client can gain access to the requested resource. It is often used in situations where network security requires authentication before granting access.

Example use cases:

• Accessing a Wi-Fi network requires authentication before connecting.

599 :

The 599 Network Connect Timeout Error status code is non-standard and is often used to indicate that a network connection timed out while waiting for a response from the server.

These 500-level status codes are crucial for both server administrators and developers, as they signal server-related issues that need to be addressed to ensure the proper functioning of web services. Monitoring and resolving these errors promptly is essential for maintaining the reliability and availability of web applications and services.

Conclusion

In conclusion, HTTP status codes play a crucial role in web development and communication between clients and servers. They provide a standardized way to convey the outcome of HTTP requests and responses, making it easier to understand and handle various scenarios in web applications and APIs.

While there are many HTTP status codes, understanding the most common ones in each category is essential for web developers. These status codes help diagnose and troubleshoot issues, ensure proper handling of requests, and improve the overall user experience. By using the right status codes and providing meaningful error messages, developers can create robust and user-friendly web applications and APIs.

In practice, mastering HTTP status codes empowers developers to build resilient and reliable systems that respond appropriately to various situations, whether it's guiding users through successful interactions or gracefully handling errors and disruptions.