The Comprehensive Server Status Code Guide

Always know your HTTP status codes with our complete guide covering statuses from 100 to 511. With notes and best practices for redirects, error handling, and SEO.

Author: Redirects.net

Published: September 19, 2025

HTTP STATUS CODES

1xx
Informational		 2xx
Success		 3xx
Redirection		 4xx
Client Error		 5xx
Server Error

What is a 100 status code?

HTTP: 100 Continue

  • When and why servers return it: The server is saying "I got the first part of your request, and it looks good so far - go ahead and send the rest!" This happens when you're trying to upload something big (like a video), and the server wants to check if you're allowed to upload before you waste time sending the whole file.
  • Practical use cases: Uploading large files to cloud storage where the server checks if you have enough space first, submitting big forms where the server validates your login before accepting all the data, or any situation where it makes sense to check permissions before transferring lots of data.
  • How clients should respond to this status: Your browser or app should immediately start sending the rest of the data. Most of the time, this happens automatically behind the scenes - you won't even notice it happening.
  • Misuses or incorrect implementations: Sending this to old browsers that don't understand it, sending it randomly when nobody asked for it, or forgetting to check if the client actually wants this two-step process before using it.
  • Mozilla.org Developer Doc for additional reference

What is a 101 status code?

HTTP: 101 Switching Protocols

  • When and why servers return it: The server agrees to change the way it communicates with you. It's like switching from texting to a phone call - you asked to upgrade the connection, and the server said "Sure, let's do it!"
  • Practical use cases: When a chat application upgrades from normal HTTP to WebSocket for real-time messaging, when a browser asks to use a faster version of HTTP, or when any application needs to switch to a different communication method for better features.
  • How clients should respond to this status: Immediately start using the new communication protocol. It's like switching languages mid-conversation - once you both agree, you start speaking the new language right away.
  • Misuses or incorrect implementations: Switching without being asked, trying to switch to something the server doesn't actually support, or forgetting to specify which protocol you're switching to.
  • Mozilla.org Developer Doc for additional reference

What is a 102 status code?

HTTP: 102 Processing

  • When and why servers return it: The server is saying "I'm still working on your request - don't give up on me!" This is used when something takes a really long time to process, so the server sends this message to prevent you from thinking it crashed.
  • Practical use cases: Converting a large video file to a different format, processing hundreds of files at once, running complex reports that take minutes to generate, or any operation that takes longer than usual to complete.
  • How clients should respond to this status: Keep waiting patiently. The server might send several of these "still working" messages before finally giving you the actual result. Don't retry the request - that would just start the whole process over again.
  • Misuses or incorrect implementations: Using this for quick operations that don't need it, sending too many "still working" messages, or forgetting to send the final response after saying you're processing.
  • Mozilla.org Developer Doc for additional reference

What is a 103 status code?

HTTP: 103 Early Hints

  • When and why servers return it: The server is giving you a heads-up about resources you'll probably need soon. It's like a restaurant telling you "while I prepare your order, you might want to get your napkins and utensils ready."
  • Practical use cases: Telling browsers to start loading CSS and JavaScript files while the server prepares the HTML, preloading fonts that the page will need, or warming up connections to other servers the page will use.
  • How clients should respond to this status: Start loading the suggested resources in the background while waiting for the real response. This makes pages feel faster because some work starts early.
  • Misuses or incorrect implementations: Sending hints but never sending the actual response, suggesting resources that aren't actually needed, or overloading the client with too many unnecessary preload hints.
  • Mozilla.org Developer Doc for additional reference

What is a 200 status code?

HTTP: 200 OK

  • When and why servers return it: This is the "everything worked perfectly" response. The server found what you wanted, did what you asked, and here's your result. It's the most common success message you'll see.
  • Practical use cases: Loading any webpage successfully, getting data from an API, downloading a file, submitting a form that worked correctly, or basically any time a request succeeds without any issues.
  • How clients should respond to this status: Use the data that came back - show the webpage, process the JSON data, save the file, or whatever makes sense for your application. This is the "normal" response that everything is designed to handle.
  • Misuses or incorrect implementations: Saying "200 OK" but including an error message in the response (confusing!), using 200 when you created something new (use 201 instead), or returning 200 with no data when data was expected.
  • Mozilla.org Developer Doc for additional reference

What is a 201 status code?

HTTP: 201 Created

  • When and why servers return it: The server successfully created something new based on your request. It's not just "OK" - it's specifically "I made the new thing you asked for!"
  • Practical use cases: Creating a new user account, posting a new tweet or status update, uploading a file that gets saved as a new resource, adding a new product to a shopping cart, or any time your request results in something new being stored.
  • How clients should respond to this status: Look for the Location header which usually tells you where to find the newly created thing. You might redirect to the new resource or update your UI to show that creation succeeded.
  • Misuses or incorrect implementations: Using 201 when updating existing things (that's what 200 is for), forgetting to include the location of the new resource, or using 201 when nothing was actually created.
  • Mozilla.org Developer Doc for additional reference

What is a 202 status code?

HTTP: 202 Accepted

  • When and why servers return it: The server accepted your request but hasn't finished processing it yet. It's like dropping off dry cleaning - they took your clothes and gave you a receipt, but the cleaning isn't done yet.
  • Practical use cases: Sending emails (accepted for delivery but not sent yet), starting a large data export that will be emailed when ready, video processing jobs, or any task that gets queued for later processing.
  • How clients should respond to this status: Don't expect immediate results. You'll need some other way to check if the job is done - maybe poll another endpoint, wait for an email, or check for a webhook notification.
  • Misuses or incorrect implementations: Using 202 for things that actually completed already, not providing any way to check on the status later, or using 202 when the task might fail (without warning the client about this possibility).
  • Mozilla.org Developer Doc for additional reference

What is a 203 status code?

HTTP: 203 Non-Authoritative Information

  • When and why servers return it: The request succeeded, but the response has been modified by something in the middle (like a proxy or cache). It's like playing telephone - the message got through, but it might have changed slightly along the way.
  • Practical use cases: When a company proxy adds or removes certain headers, when a caching server modifies responses to save bandwidth, or when content filters adjust what you see based on policies.
  • How clients should respond to this status: Use the response normally, but know that it might not be exactly what the original server sent. It's still valid, just potentially modified.
  • Misuses or incorrect implementations: Not being transparent about modifications, using 203 when nothing was actually changed, or modifying responses in ways that break functionality.
  • Mozilla.org Developer Doc for additional reference

What is a 204 status code?

HTTP: 204 No Content

  • When and why servers return it: The server successfully did what you asked but has nothing to send back. It's like successfully deleting something - the deletion worked, but there's nothing to show you because it's gone!
  • Practical use cases: Deleting records, updating settings where you don't need confirmation data back, saving preferences silently in the background, or any successful action where a response body would be pointless.
  • How clients should respond to this status: Treat it as success but don't expect any data. Perfect for AJAX requests where you just need to know something worked. The page shouldn't refresh or change unless your JavaScript decides to update something.
  • Misuses or incorrect implementations: Including response data with a 204 (that's not allowed!), using 204 when the client probably wants to see the updated data, or using 204 for errors.
  • Mozilla.org Developer Doc for additional reference

What is a 205 status code?

HTTP: 205 Reset Content

  • When and why servers return it: The server is telling your application to clear its form or reset its view. It's like successfully submitting a survey and having the form automatically clear itself for the next person.
  • Practical use cases: After submitting a data entry form that needs to be used repeatedly, completing a survey that should reset for the next respondent, or any situation where the UI should return to its starting state after success.
  • How clients should respond to this status: Clear all form fields, reset the document view, or return the interface to its original state. No data comes with this response - it's just an instruction to reset.
  • Misuses or incorrect implementations: Sending data with a 205 response (it should be empty), using 205 when you don't actually want the form cleared, or using it when a simple 204 would be better.
  • Mozilla.org Developer Doc for additional reference

What is a 206 status code?

HTTP: 206 Partial Content

  • When and why servers return it: The server is sending only part of the file because that's what you asked for. It's like asking for pages 50-60 of a book instead of the whole book.
  • Practical use cases: Streaming video where you can jump to different parts, resuming interrupted downloads from where they stopped, downloading large files in chunks, or implementing "load more" features efficiently.
  • How clients should respond to this status: Process the partial content and potentially request more parts if needed. Video players use this for seeking, and download managers use it for resuming.
  • Misuses or incorrect implementations: Sending 206 when nobody asked for partial content, sending the wrong byte range, not supporting range requests when they would be helpful, or messing up the Content-Range headers.
  • Mozilla.org Developer Doc for additional reference

What is a 207 status code?

HTTP: 207 Multi-Status

  • When and why servers return it: Multiple operations were performed and each one has its own result. It's like submitting a batch of job applications and getting individual responses for each one in a single envelope.
  • Practical use cases: Bulk operations where you're updating multiple items at once, WebDAV operations on multiple files, batch API requests, or any time you need to report individual results for multiple operations.
  • How clients should respond to this status: Parse the response body (usually XML) to see the individual result for each operation. Some might have succeeded while others failed, and you need to handle each appropriately.
  • Misuses or incorrect implementations: Using 207 for single operations, not structuring the multi-status response correctly, or using it when all operations had the same result (just use that single status code instead).
  • Mozilla.org Developer Doc for additional reference

What is a 208 status code?

HTTP: 208 Already Reported

  • When and why servers return it: In a multi-status response, this indicates information about this resource was already included earlier. It's like saying "see above" to avoid repeating yourself.
  • Practical use cases: When listing directory contents that include symbolic links, preventing infinite loops in recursive operations, or avoiding duplicate information in complex WebDAV responses.
  • How clients should respond to this status: Skip processing this resource since you already handled it earlier in the response. This prevents double-processing and infinite loops.
  • Misuses or incorrect implementations: Using 208 outside of proper multi-status contexts, marking things as "already reported" when they weren't, or creating confusing responses by overusing this status.
  • Mozilla.org Developer Doc for additional reference

What is a 226 status code?

HTTP: 226 IM Used

  • When and why servers return it: The server applied one or more transformations to the response. It's like ordering a document and receiving a compressed or optimized version to save bandwidth.
  • Practical use cases: Delta encoding where only changes since last time are sent, compression systems that transform content on the fly, or any bandwidth-saving transformation that the client requested.
  • How clients should respond to this status: Process the transformed content using the method indicated in the headers. The client needs to understand the transformation to use the response properly.
  • Misuses or incorrect implementations: Using 226 without indicating what transformations were applied, applying transformations the client didn't request, or using 226 for standard compression (which doesn't need a special status).
  • Mozilla.org Developer Doc for additional reference

What is a 305 status code?

HTTP: 305 Use Proxy

  • When and why servers return it: This status code is deprecated and should never be used. It had security problems and has been abandoned by the web community.
  • Practical use cases: None - this status code is retired and shouldn't be used in any modern application.
  • How clients should respond to this status: Modern clients should ignore this status code due to security concerns. It's a historical artifact.
  • Misuses or incorrect implementations: Using this status code at all is a mistake. It's deprecated for good security reasons and should never appear in modern applications.
  • Mozilla.org Developer Doc for additional reference

What is a 300 status code?

HTTP: 300 Multiple Choices

  • When and why servers return it: There are multiple versions of the requested resource and the server can't pick one automatically. It's like asking for "the manual" when there are versions in different languages.
  • Practical use cases: When content is available in multiple languages or formats, when there are different versions for different devices, or when the server genuinely can't decide which version you want.
  • How clients should respond to this status: Present the choices to the user or pick one based on preferences (like language settings). The response should list all available options.
  • Misuses or incorrect implementations: Using 300 when the server could reasonably pick a default, not clearly presenting the available choices, or using it for simple redirects (use 301/302 instead).
  • Mozilla.org Developer Doc for additional reference

What is a 301 status code?

HTTP: 301 Moved Permanently

  • When and why servers return it: The resource has permanently moved to a new address. It's like when a business moves to a new location and puts up a permanent forwarding sign - update your address book!
  • Practical use cases: When websites restructure their URLs permanently, moving from HTTP to HTTPS, when companies rebrand and change domains, or consolidating multiple pages into one for better organization.
  • How clients should respond to this status: Automatically go to the new URL and remember it for next time. Browsers update bookmarks, and search engines update their indexes to point to the new location.
  • Misuses or incorrect implementations: Using 301 for temporary moves (use 302 instead), creating chains of redirects that bounce users around, or using 301 when you might want to change it back later.
  • Mozilla.org Developer Doc for additional reference

What is a 302 status code?

HTTP: 302 Found

  • When and why servers return it: The resource is temporarily at a different location. It's like a store sign saying "We're at the farmer's market today" - they'll be back at their normal spot tomorrow.
  • Practical use cases: Redirecting users during site maintenance, A/B testing where some users go to a different version, seasonal promotions that redirect to special pages, or load balancing between servers.
  • How clients should respond to this status: Go to the temporary location for now, but keep using the original URL for future requests. Don't update bookmarks or permanent references.
  • Misuses or incorrect implementations: Using 302 for permanent moves (use 301 for those), creating redirect loops where A sends to B and B sends back to A, or using 302 when you specifically need to preserve the HTTP method (use 307).
  • Mozilla.org Developer Doc for additional reference

What is a 303 status code?

HTTP: 303 See Other

  • When and why servers return it: After processing your request (usually POST), the server wants you to look at a different page using GET. It's like submitting a form and being redirected to a "thank you" page.
  • Practical use cases: After submitting a form, redirect to a confirmation page; after making a payment, redirect to a receipt; any time you want to prevent duplicate submissions when users refresh the page.
  • How clients should respond to this status: Make a fresh GET request to the new URL. This prevents accidental resubmission if users refresh the page, since refreshing will just reload the final page, not resubmit the form.
  • Misuses or incorrect implementations: Using 303 when you want to preserve the original method (use 307), using it for permanent redirects (use 301), or forgetting that the redirect will always use GET regardless of the original method.
  • Mozilla.org Developer Doc for additional reference

What is a 304 status code?

HTTP: 304 Not Modified

  • When and why servers return it: The resource hasn't changed since you last requested it, so use your cached copy. It's like checking if a document was updated and being told "nope, still the same."
  • Practical use cases: Browser caching where it checks if images/CSS/JavaScript files have changed, API responses that rarely change, or any situation where you want to save bandwidth by not resending unchanged data.
  • How clients should respond to this status: Use the cached version you already have. No new data comes with this response - it's just confirming your cached copy is still good.
  • Misuses or incorrect implementations: Sending data with a 304 (it must be empty), saying "not modified" when it actually was modified, or not properly handling the special headers that make this work.
  • Mozilla.org Developer Doc for additional reference

What is a 307 status code?

HTTP: 307 Temporary Redirect

  • When and why servers return it: Temporarily redirect to another URL, but unlike 302, the client must use the same method. If the original request was POST, the redirect must also be POST.
  • Practical use cases: API endpoints under maintenance that need to preserve the method, load balancing that maintains request integrity, or any temporary redirect where changing from POST to GET would break things.
  • How clients should respond to this status: Redirect to the new URL using the exact same method and body as the original request. This is stricter than 302 redirects.
  • Misuses or incorrect implementations: Using 307 for permanent moves (use 308), using it when method preservation doesn't matter (302 is simpler), or not realizing that clients must resend the request body.
  • Mozilla.org Developer Doc for additional reference

What is a 308 status code?

HTTP: 308 Permanent Redirect

  • When and why servers return it: Like 301, but guarantees the method won't change. If you POSTed to the old URL, you must POST to the new URL too.
  • Practical use cases: Permanently moving API endpoints that accept POST/PUT/DELETE, restructuring RESTful services while maintaining method integrity, or any permanent move where the HTTP method must be preserved.
  • How clients should respond to this status: Permanently update references to use the new URL, and always use the same HTTP method as the original request when following the redirect.
  • Misuses or incorrect implementations: Using 308 for temporary moves (use 307), using it when method preservation doesn't matter (301 is more widely supported), or forgetting this is a newer status code that older clients might not understand.
  • Mozilla.org Developer Doc for additional reference

What is a 400 status code?

HTTP: 400 Bad Request

  • When and why servers return it: Your request is malformed or invalid in some way. It's like filling out a form with your email in the phone number field - the server can't process it because it doesn't make sense.
  • Practical use cases: Invalid JSON in the request body, missing required parameters, wrong data types (sending text when a number is expected), malformed URLs, or any syntax error in the request.
  • How clients should respond to this status: Don't retry the same request - it will fail again. Fix the problem first. Check the response body for details about what's wrong and correct it before trying again.
  • Misuses or incorrect implementations: Using 400 for authentication problems (use 401), returning 400 for server errors (use 5xx), giving vague error messages that don't help fix the problem, or using 400 as a catch-all for any error.
  • Mozilla.org Developer Doc for additional reference

What is a 401 status code?

HTTP: 401 Unauthorized

  • When and why servers return it: You need to log in or provide credentials to access this resource. It's like trying to enter a members-only area without showing your membership card.
  • Practical use cases: Accessing protected API endpoints without a token, expired login sessions, missing API keys, or any request to a resource that requires you to prove who you are.
  • How clients should respond to this status: Prompt the user to log in, redirect to a login page, or obtain valid credentials before retrying. For APIs, get a fresh authentication token.
  • Misuses or incorrect implementations: Using 401 when credentials are valid but insufficient (use 403), forgetting to include information about how to authenticate, or confusing authentication (who you are) with authorization (what you're allowed to do).
  • Mozilla.org Developer Doc for additional reference

What is a 403 status code?

HTTP: 403 Forbidden

  • When and why servers return it: The server understands who you are but won't let you access this resource. It's like showing your ID to enter a VIP area but being told you're not on the list.
  • Practical use cases: Trying to access admin features as a regular user, attempting to view another user's private data, geographic restrictions (content not available in your country), or IP address blocking.
  • How clients should respond to this status: Don't bother retrying with the same credentials - they won't work. Show an "access denied" message and possibly explain how to get proper access if applicable.
  • Misuses or incorrect implementations: Using 403 when the user isn't logged in (use 401), using 403 for resources that don't exist to hide their existence (debatable - might use 404), or not being clear about why access is forbidden.
  • Mozilla.org Developer Doc for additional reference

What is a 404 status code?

HTTP: 404 Not Found

  • When and why servers return it: The server can't find anything at the URL you requested. It's like going to a street address where there's just an empty lot - either you got the address wrong, or whatever used to be there is gone.
  • Practical use cases: Typing a URL incorrectly (like gooogle.com instead of google.com), clicking old bookmarks to pages that were deleted, following broken links from other websites, making typos in API endpoints, or trying to access files that were moved or renamed.
  • How clients should respond to this status: Show an error page that helps users figure out what to do next. Good 404 pages include a search box, links to popular pages, a way to report the broken link, or even a fun message to make the error less frustrating.
  • Misuses or incorrect implementations: Using 404 when access is denied (use 403 for "you can't see this"), returning 404 for things that were intentionally removed forever (consider 410 "Gone"), showing generic unhelpful error pages, or using 404 to hide that something exists from unauthorized users (though this is debatable for security).
  • Mozilla.org Developer Doc for additional reference

What is a 405 status code?

HTTP: 405 Method Not Allowed

  • When and why servers return it: The resource exists but doesn't support the HTTP method you used. It's like trying to push a door that only opens by pulling - the door exists, you just need to use it correctly.
  • Practical use cases: Trying to DELETE a resource that's read-only, sending POST to an endpoint that only accepts GET, attempting PUT on resources that can't be updated, or using custom methods the server doesn't support.
  • How clients should respond to this status: Check the Allow header to see which methods are supported, then retry with an appropriate method. Don't keep trying the same method - it's not supported.
  • Misuses or incorrect implementations: Not including the required Allow header listing supported methods, using 405 when the resource doesn't exist (use 404), or returning 405 for methods the server should support but hasn't implemented yet (consider 501).
  • Mozilla.org Developer Doc for additional reference

What is a 406 status code?

HTTP: 406 Not Acceptable

  • When and why servers return it: The server can't provide the resource in a format you'll accept. It's like asking for a menu in French at a restaurant that only has English and Spanish versions.
  • Practical use cases: Requesting JSON from an endpoint that only provides XML, asking for an image format the server doesn't support, language negotiation failures, or any content negotiation mismatch.
  • How clients should respond to this status: Modify your Accept headers to request a format the server can provide, or handle the available formats. The response might list what formats are available.
  • Misuses or incorrect implementations: Being too strict about formats when you could provide a reasonable default, using 406 for non-content negotiation errors, or not clearly indicating what formats are available.
  • Mozilla.org Developer Doc for additional reference

What is a 407 status code?

HTTP: 407 Proxy Authentication Required

  • When and why servers return it: A proxy server between you and the destination requires authentication. It's like needing to show ID to the security guard before you can even get to the building you want to enter.
  • Practical use cases: Corporate proxy servers requiring employee login, network gateways that need authentication, paid proxy services requiring credentials, or any authenticated proxy setup.
  • How clients should respond to this status: Authenticate with the proxy server (not the destination server) using the method specified in the Proxy-Authenticate header, then retry the original request.
  • Misuses or incorrect implementations: Confusing this with regular 401 authentication, not including the Proxy-Authenticate header, or using 407 when it's the destination server (not proxy) requiring authentication.
  • Mozilla.org Developer Doc for additional reference

What is a 408 status code?

HTTP: 408 Request Timeout

  • When and why servers return it: The server waited for you to send the complete request, but you took too long. It's like starting to order at a restaurant but pausing so long the waiter walks away.
  • Practical use cases: Slow network connections causing delays, large file uploads over poor connections, client applications that freeze during request transmission, or network interruptions while sending data.
  • How clients should respond to this status: You can retry the request, preferably with a better connection or smaller payload. Consider breaking large requests into smaller chunks or improving network conditions.
  • Misuses or incorrect implementations: Using 408 when the server is slow (that's 504), setting unreasonably short timeouts, or using 408 for application-level timeouts rather than network-level ones.
  • Mozilla.org Developer Doc for additional reference

What is a 409 status code?

HTTP: 409 Conflict

  • When and why servers return it: Your request conflicts with the current state of the resource. It's like trying to create a username that's already taken - the operation makes sense, but it can't be done right now.
  • Practical use cases: Trying to create a duplicate record, editing a document that someone else is currently editing, version conflicts in collaborative systems, or violating business rules (like double-booking a resource).
  • How clients should respond to this status: Resolve the conflict by choosing a different value, merging changes, or waiting for the conflict to clear. The response should explain what the conflict is and how to resolve it.
  • Misuses or incorrect implementations: Using 409 for validation errors (consider 422), not explaining how to resolve the conflict, using 409 for permission issues (use 403), or reporting conflicts that aren't actually resolvable by the client.
  • Mozilla.org Developer Doc for additional reference

What is a 410 status code?

HTTP: 410 Gone

  • When and why servers return it: The resource used to exist here but was deliberately removed and won't come back. It's like visiting a demolished building - it's not just temporarily closed, it's permanently gone.
  • Practical use cases: Articles or posts that were deleted for policy violations, products that are discontinued forever, old API versions that have been sunset, or any content intentionally and permanently removed.
  • How clients should respond to this status: Remove bookmarks, update links, and inform users the content is permanently gone. Search engines should remove these URLs from their index. Don't keep checking - it's not coming back.
  • Misuses or incorrect implementations: Using 410 for temporary removals (use 503), using 410 when you might restore the content, using 410 for things that never existed (use 404), or not being certain the removal is permanent.
  • Mozilla.org Developer Doc for additional reference

What is a 418 status code?

HTTP: 418 I'm a teapot

  • When and why servers return it: This is a joke status code from an April Fools' RFC about controlling coffee pots. It means "I'm a teapot, and you asked me to brew coffee, which I can't do."
  • Practical use cases: Easter eggs in applications, demonstrating HTTP's extensibility in programming courses, adding humor to development/test environments, or as a playful response in appropriate contexts.
  • How clients should respond to this status: Recognize it as a humorous response and handle appropriately - maybe display a fun error message or tea-related imagery. Don't expect this in serious production environments.
  • Misuses or incorrect implementations: Using 418 for actual errors in production systems, overusing it to the point of annoyance, or returning it to users who won't understand the joke.
  • Mozilla.org Developer Doc for additional reference

What is a 422 status code?

HTTP: 422 Unprocessable Entity

  • When and why servers return it: Your request format is correct, but the content doesn't make sense. It's like filling out a form correctly but entering impossible data - like being 300 years old or born in the future.
  • Practical use cases: Form validation failures (email without @ symbol), business rule violations (end date before start date), semantic errors in API requests, or any logical errors in correctly formatted data.
  • How clients should respond to this status: Read the error details to understand what validation failed, fix the data to meet requirements, and resubmit. The structure was fine; the content needs adjustment.
  • Misuses or incorrect implementations: Using 422 for syntax errors (use 400), not providing specific validation error details, using 422 for authentication/authorization issues, or being inconsistent about what triggers 422 vs 400.
  • Mozilla.org Developer Doc for additional reference

What is a 429 status code?

HTTP: 429 Too Many Requests

  • When and why servers return it: You're sending too many requests too quickly. It's like calling someone repeatedly - eventually they'll stop answering and tell you to slow down.
  • Practical use cases: API rate limiting (e.g., 100 requests per hour), preventing abuse or DDoS attacks, protecting servers from being overwhelmed, or enforcing fair usage policies.
  • How clients should respond to this status: Stop making requests and wait. Check the Retry-After header to see when you can try again. Implement exponential backoff - wait longer between each retry attempt.
  • Misuses or incorrect implementations: Not including Retry-After header to guide clients, setting limits too low for normal usage, using 429 for other types of overload (consider 503), or not clearly documenting rate limits.
  • Mozilla.org Developer Doc for additional reference

What is a 451 status code?

HTTP: 451 Unavailable For Legal Reasons

  • When and why servers return it: Content is blocked due to legal requirements. Named after Ray Bradbury's "Fahrenheit 451" about censorship, this status indicates government or legal blocking.
  • Practical use cases: Content blocked by court order, DMCA takedown notices, geographic restrictions due to local laws, government censorship requirements, or any legally mandated content blocking.
  • How clients should respond to this status: Inform users that content is legally restricted. The response might include details about who demanded the block (if that's legally allowed to share).
  • Misuses or incorrect implementations: Using 451 for non-legal blocks (use appropriate 4xx code), not being transparent about legal blocks when possible, or using 451 for voluntary content policies rather than legal requirements.
  • Mozilla.org Developer Doc for additional reference

What is a 500 status code?

HTTP: 500 Internal Server Error

  • When and why servers return it: Something went wrong on the server's end, and it doesn't know how to handle it. It's like a cash register crashing at a store - the problem isn't with your payment method, their system just broke.
  • Practical use cases: When the database connection fails, when there's a bug in the server code, when the server runs out of memory, or any unexpected crash that the programmers didn't anticipate.
  • How clients should respond to this status: Tell users something went wrong and suggest trying again later. You might automatically retry after a delay, since these errors are often temporary.
  • Misuses or incorrect implementations: Using 500 for user errors (use 4xx codes for those), showing detailed error messages to users (security risk!), not logging enough details to fix the problem, or using 500 as a lazy catch-all for any error.
  • Mozilla.org Developer Doc for additional reference

What is a 501 status code?

HTTP: 501 Not Implemented

  • When and why servers return it: The server doesn't support the functionality you're asking for. It's like asking a basic calculator to graph functions - it understands what you want but doesn't have that feature.
  • Practical use cases: Using HTTP methods the server doesn't recognize, requesting features that are planned but not built yet, legacy servers that don't support modern functionality, or custom methods that aren't implemented.
  • How clients should respond to this status: Don't retry this request - the server can't handle it. Use a different approach or check if there's an alternative way to achieve what you need.
  • Misuses or incorrect implementations: Using 501 for temporarily disabled features (use 503), using 501 for methods you recognize but don't allow (use 405), or using 501 as an excuse for missing features that should be implemented.
  • Mozilla.org Developer Doc for additional reference

What is a 502 status code?

HTTP: 502 Bad Gateway

  • When and why servers return it: A server acting as a gateway or proxy received an invalid response from an upstream server. It's like asking someone to relay a message, but they come back saying "the person I asked gave me gibberish."
  • Practical use cases: Load balancer can't reach backend servers, API gateway receiving errors from microservices, reverse proxy getting malformed responses, or CDN unable to fetch from origin server.
  • How clients should respond to this status: This is usually temporary, so retry after a short delay. The problem is between servers, not with your request, so retrying might work once they fix their communication issues.
  • Misuses or incorrect implementations: Using 502 for the origin server's own errors (use 500), not distinguishing between "can't reach" and "invalid response" scenarios, or using 502 when the gateway itself has problems.
  • Mozilla.org Developer Doc for additional reference

What is a 503 status code?

HTTP: 503 Service Unavailable

  • When and why servers return it: The server is temporarily unable to handle requests. It's like a store putting up a "closed for maintenance" sign - they'll be back, but not right now.
  • Practical use cases: Scheduled maintenance windows, server overload situations, temporary outages for updates, rate limiting at the server level, or any temporary inability to serve requests.
  • How clients should respond to this status: Wait and retry later. Check the Retry-After header for guidance on when to come back. Implement exponential backoff for retries to avoid overwhelming the server when it returns.
  • Misuses or incorrect implementations: Using 503 for permanent problems (use appropriate error), not including Retry-After when you know how long it'll take, using 503 for client-specific issues rather than server-wide problems.
  • Mozilla.org Developer Doc for additional reference

What is a 504 status code?

HTTP: 504 Gateway Timeout

  • When and why servers return it: A server acting as a gateway or proxy didn't receive a timely response from an upstream server. It's like asking someone to relay a message, but they come back saying "I waited and waited, but they never responded."
  • Practical use cases: Database queries taking too long, overloaded backend services, network issues between servers, microservices not responding quickly enough, or any timeout in server-to-server communication.
  • How clients should respond to this status: You can retry, but be aware the operation might be expensive or slow. Consider if the request is critical enough to retry, and implement reasonable retry limits.
  • Misuses or incorrect implementations: Using 504 when clients are slow (use 408), setting timeouts too short for reasonable operations, not distinguishing between different timeout scenarios, or using 504 for the origin server's own timeouts.
  • Mozilla.org Developer Doc for additional reference

What is a 505 status code?

HTTP: 505 HTTP Version Not Supported

  • When and why servers return it: The server doesn't support the HTTP version used in the request. It's like trying to play a Blu-ray disc in a DVD player - the player understands what you want but can't handle that format.
  • Practical use cases: Old servers that only support HTTP/1.0 receiving HTTP/2 requests, servers not yet upgraded to support newer HTTP versions, or custom/experimental HTTP versions the server doesn't recognize.
  • How clients should respond to this status: Retry the request using a different HTTP version, typically falling back to HTTP/1.1 which is universally supported. Check what versions the server does support.
  • Misuses or incorrect implementations: Using 505 for unsupported features within a version (use 501), not attempting to handle version negotiation gracefully, or rejecting standard HTTP versions that should be supported.
  • Mozilla.org Developer Doc for additional reference

What is a 507 status code?

HTTP: 507 Insufficient Storage

  • When and why servers return it: The server doesn't have enough storage space to complete the request. It's like trying to save a file when the hard drive is full.
  • Practical use cases: File upload failures due to full disk, database operations hitting storage quotas, WebDAV operations exceeding allocated space, or any operation that requires more storage than available.
  • How clients should respond to this status: Inform users about storage limits. Might need to delete old content, request more storage, or reduce the size of what you're trying to store.
  • Misuses or incorrect implementations: Using 507 for temporary storage issues that will clear up (consider 503), not monitoring storage properly, using 507 for quota issues unrelated to physical storage, or not providing information about storage limits.
  • Mozilla.org Developer Doc for additional reference

What is a 508 status code?

HTTP: 508 Loop Detected

  • When and why servers return it: The server detected an infinite loop while processing the request. It's like following directions that say "see step 1" at the end - you'd go in circles forever.
  • Practical use cases: WebDAV operations with circular references, redirect chains that loop back on themselves, symbolic links that create cycles, or any server operation that detects it's repeating endlessly.
  • How clients should respond to this status: Don't retry the same request - it will hit the same loop. Check for circular references in your data structure and fix them before trying again.
  • Misuses or incorrect implementations: Using 508 for non-loop errors, not implementing proper loop detection, using 508 for client-side redirect loops (those show up differently), or detecting false positives as loops.
  • Mozilla.org Developer Doc for additional reference

What is a 511 status code?

HTTP: 511 Network Authentication Required

  • When and why servers return it: You need to authenticate with the network itself before you can access the internet. It's like needing to sign in to hotel WiFi before you can browse any websites.
  • Practical use cases: Hotel or airport WiFi login pages, corporate network access portals, public WiFi that requires accepting terms of service, or any captive portal situation.
  • How clients should respond to this status: Redirect users to the network login page (usually provided in the response). Once they authenticate with the network, they can retry their original request.
  • Misuses or incorrect implementations: Using 511 for website login requirements (use 401), using 511 for proxy authentication (use 407), or implementing captive portals in ways that break secure connections.
  • Mozilla.org Developer Doc for additional reference

What is a XXX status code?

XXX Status Name