 |
When communicating via HTTP (HyperText Transfer Protocol), servers respond with status code to indicate the outcome of the request made by a client (such as a browser).
These codes are divided into five families, each with a specific meaning.
🔵 1xx – Informative
This family of codes indicates that the request has been received and the process is in progress. They are rarely visible on the user side, but can be useful in the client-server dialogue.
100 Continue
Description: The server has received the start of the request and the client can continue sending the request body.
Example: A client is uploading a large file and sends an Expect: 100-continue header. The server responds with 100 Continue to confirm that it can proceed with sending the content.
101 Switching Protocols
Description: The server agrees to switch protocols as requested by the client.
Example: A client requests to switch from HTTP to WebSocket, and the server confirms with this code.
🟢 2xx – Success
🔹 200 OK
Description: The request was successfully processed by the server and a response with any data is returned.
Example: A client sends a GET /api/users/123 request to get the user data with ID 123.
The server responds:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"name": "Marco Rossi",
"email": "marco@example.com"
}
This status code is also used for PUT, POST or DELETE when no other code is required.
🔹 201 Created
Description: A new resource was successfully created. The Location header can indicate the URL of the new resource.
Example: A client application sends a POST /api/articles request with the request body:
{
"title": "HTTP Status Code Guide",
"author": "Alice Bianchi"
}The server creates the article and responds:
HTTP/1.1 201 Created
Location: /api/articles/457
Content-Type: application/json
{
"id": 457,
"title": "HTTP Status Code Guide",
"author": "Alice Bianchi"
}
🔹 202 Accepted
Description: The request has been received and accepted, but not yet completed.
Example: A user sends a POST to /api/reports/generate to generate a report.
The server responds:
HTTP/1.1 202 Accepted
Content-Type: application/json
{
"message": "Report generation has started.",
"reportId": "rep-9021"
}
The client can then check the status of the report with another request (GET /api/reports/status/rep-9021).
🔹 204 No Content
Description: The request was successful, but there is nothing to return in the response body.
Example: A client sends a DELETE /api/comments/55 request to delete a comment.
The server responds:
HTTP/1.1 204 No Content
No body returned because the operation completed and there is no additional data.
🔹 206 Partial Content
Description: The server returns only a portion of the resource, usually in response to a request with the Range header.
Example: A client requests the first 500 bytes of a video:
GET /video.mp4
Range: bytes=0-499
>The server responds:
>HTTP/1.1 206 Partial Content
Content-Range: bytes 0-499/10000
Content-Type: video/mp4
This is typical in progressive downloads, such as video players or resumable downloads.
🟡 3xx – Redirections
Indicate that the client has further steps to take actions to complete the request. They are typically used for URL redirects.
3xx codes are essential for transition management, SEO optimization, caching content management, and secure navigation in web application flows.
〽️ 300 Multiple Choices
Description: The requested resource has multiple valid representations, and the server provides a list of options to choose from.
Example: A request to /video might return either /video.mp4 or /video.webm. The server responds with a list and 300.
〽️ 301 Moved Permanently
Description: The requested resource has been permanently moved to a new URL.
Example: A site moves content from http://example.com to https://www.example.com. Requests to http://example.com receive 301 and the Location: https://www.example.com header.
〽️ 302 Found
Description: The requested resource is temporarily located in a new location.
Example: Accessing /dashboard as an unauthenticated user causes a redirect to /login with code 302, but the location is not final.
〽️ 303 See Other
Description: The client must make a GET request to another URL to obtain the resource.
Example: After submitting an order via POST to /order, the server responds 303 See Other with Location: /order/confirmation.
〽️ 304 Not Modified
Description: Indicates that the cached version of the resource is still valid; no data will be retransmitted.
Example: The browser requests /style.css with the header If-Modified-Since: [data]. If the file has not changed, the server returns 304.
〽️ 305 Use Proxy (Deprecated)
Description: Indicates that the requested resource is only available through a specific proxy.
Example: No longer used for security reasons.
〽️ 306 (Unused)
Description: Reserved; no longer used.
Example: Has no current practical application.
〽️ 307 Temporary Redirect
Description: Temporary redirect where the original HTTP method should be preserved.
Example: POST to /pay returns 307 to /maintenance, and the client retries the POST.
〽️ 308 Permanent Redirect
Description: Like 301, but forces the client to keep the original HTTP method.
Example: An API deprecates /v1/data in favor of /v2/data and responds with 308 for all calls to /v1/data.
🟠 4xx – Client Errors
Indicates that the request sent by the client has an error. This could be a syntax error, authorization error, or resource unavailability.
4xx codes are essential for accurately handling client-side errors, protecting resources, and providing clear feedback to improve user experience and security.
🔸 400 Bad Request
Description: The request syntax is incorrect or uninterpretable.
Example: An app sends malformed JSON to /api/login:
POST /api/login
Content-Type: application/json
{ username: "mario" password: "pwd" }Response:
HTTP/1.1 400 Bad Request🔸 401 Unauthorized
Description: The request requires user authentication, but it was not provided or failed.
Example: A request to /api/profile without an access token returns:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer🔸 403 Forbidden
Description: The server understood the request but refuses to authorize it.
Example: A non-administrator user accesses /admin/settings.
🔸 404 Not Found
Description: The requested resource was not found on the server.
Example: The user accesses /api/products/9999, but the ID does not exist in the database.
🔸 405 Method Not Allowed
Description: The HTTP method used is not allowed for the endpoint.
Example: You send a POST request to an endpoint that only accepts GET.
🔸 406 Not Acceptable
Description: The server cannot return a response that matches the Accept headers of the request.
Example: Client sends:
Accept: application/xmlbut server can only return JSON → 406.
🔸 409 Conflict
Description: There is a conflict with the current state of the resource. Example: Two users simultaneously edit a profile and send inconsistent updates.
🔸 410 Gone
Description: The resource is no longer available and will not return. Example: A page has been permanently removed, and the server wants to signal that it will not be restored.
🔸 415 Unsupported Media Type
Description: The request's content type is not supported by the server.
Example: The app sends a request with Content-Type: text/csv to an endpoint that only accepts JSON.
🔸 422 Unprocessable Entity
Description: The request data is well-formed but semantically incorrect. Example: User submits a form with a missing email field:
POST /register
{
"username": "giulia"
}Response:
HTTP/1.1 422 Unprocessable Entity🔸 429 Too Many Requests
Description: The client made too many requests in too short a time (rate limiting).
Example: A bot sends hundreds of requests to /api/search in a few seconds or when there is an infinite redirect loop (perhaps because there were errors in configuring the 3xx codes creating redirects that point to other redirects).
🔴 5xx – Server Errors
5xx codes indicate server-side problems and help clients and developers distinguish between network errors, temporary glitches, and unavailable functionality.
500 Internal Server Error
Description: Generic server error. Something went wrong, but it is not specified.
Example: An application throws an unhandled exception while processing a request to /checkout.
501 Not Implemented
Description: The server does not support the requested functionality.
Example: The client sends a request with the PATCH method, but the server has not implemented it.
502 Bad Gateway
Description: The server is acting as a gateway/proxy and receives an invalid response from the upstream server.
Example: A reverse proxy sends a request to a backend that is turned off or misconfigured.
503 Service Unavailable
Description: The server is temporarily unavailable, often due to maintenance or overload.
Example: While a site is being updated, all requests return 503.
504 Gateway Timeout
Description: The server is acting as a gateway and is not receiving a response in time from the upstream server.
Example: A remote API server is slow or is not responding within the gateway timeout.
505 HTTP Version Not Supported
Description: The server does not support the HTTP version used in the request.
Example: The client is using HTTP/0.9 or an unknown version.
🎯 Summary tables
📋 Summary
| Family | Code | Description |
|---|---|---|
| 1xx | Informational | Requests received, server continues processing |
| 2xx | Success | The request was completed successfully |
| 3xx | Redirection | The client must perform further actions (e.g. redirect) |
| 4xx | Client Error | Errors in the request attributable to the client |
| 5xx | Server Error | Server errors processing request |
⚙️ Typical use
| Family | Code | Typical use |
|---|---|---|
| 1xx | Informational | Used in advanced protocols, e.g. `100 Continue` |
| 2xx | Success | Confirm successful actions: login, resource creation, saving |
| 3xx | Redirection | Management of redirects and caching (e.g. `301`, `302`, `304`) |
| 4xx | Client Error | User-side error handling: 404, 401, 422, 429 |
| 5xx | Server Error | Indication of internal server errors or malfunctions |
Conclusion
Understanding HTTP status codes is essential for developing, testing, and maintaining web applications. They provide clear communication between client and server and help quickly identify problems or confirm the success of a request.
Follow me #techelopment
Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment
