HTTP Status Codes

The server received the request headers and the client should send the body. Sent after an Expect: 100-continue.

The server is switching protocols as the client asked — e.g. upgrading to WebSocket.

WebDAV: the server has accepted the request but has not completed it yet.

Lets the browser start preloading resources (Link headers) while the final response is prepared.

The standard success response. The body contains the requested resource.

The request succeeded and a new resource was created — typically after a POST. Look for a Location header.

The request was accepted for processing but is not complete (async/queued work).

Success, but the returned metadata was modified by a proxy.

Success with no body to return — common for DELETE or a saved form with no redirect.

Success; the client should reset the document view (e.g. clear a form).

The server is delivering only part of the resource (a Range request) — used for resumable downloads and video streaming.

WebDAV: the body contains multiple status codes for multiple operations.

The response is the result of instance-manipulations (delta encoding).

The resource has several representations; the client or user should pick one.

The resource moved for good. Update links and bookmarks. SEO: passes ranking signals to the new URL. Use for www→root, http→https, old→new URLs.

A temporary redirect. The original URL should still be used in future. For SEO prefer 301 for permanent moves; 302 keeps indexing on the original.

Redirect with a forced GET — the POST-Redirect-GET pattern after a form submit, to avoid duplicate submissions.

The cached copy is still valid (conditional request with ETag / If-Modified-Since). Saves bandwidth — this is normal and good.

Like 302 but the method (POST/GET) must not change. Safer than 302 for non-GET requests.

Like 301 but the method must not change. Use for permanent moves of POST endpoints.

The server could not parse the request — malformed JSON, invalid query string, bad headers. Fix: validate the payload and Content-Type.

Authentication is required or failed. Fix: send valid credentials / a valid token (Authorization header). Note the misnomer — it means "unauthenticated".

Reserved for future/payment use — some APIs return it when a plan limit or billing issue is hit.

The server understood the request but refuses it. You are authenticated but not allowed. Causes: file permissions, IP/geo block, missing index, WAF rule, directory listing disabled.

The URL does not exist on the server. Causes: typo, deleted page, broken link, wrong rewrite rule. Fix: 301-redirect old URLs, check your router/.htaccess.

The URL exists but not for that HTTP method (e.g. POST to a GET-only endpoint). Check the Allow header.

The server cannot produce a response matching the Accept headers the client sent.

Like 401 but you must authenticate with a proxy first.

The client was too slow sending the request; the server closed the connection.

The request conflicts with the current state — e.g. an edit conflict or a duplicate unique key.

The resource was intentionally removed and will not come back. Stronger than 404 — tells search engines to drop the URL.

The server needs a Content-Length header.

A conditional header (If-Match / If-Unmodified-Since) failed — often optimistic-locking.

The body is bigger than the server allows. Fix: raise client_max_body_size (nginx) / upload_max_filesize (PHP).

The URL is longer than the server accepts — move data into the body.

The Content-Type is not supported (e.g. sending XML to a JSON-only API).

The requested byte Range is invalid for the resource.

The server cannot meet the Expect request header.

An April Fools RFC joke — returned by some servers for fun or to block bots.

The request reached a server that cannot produce a response for the authority (TLS/SNI mismatch).

The syntax is fine but the data fails validation (semantic errors). Very common in REST/JSON APIs — read the error body.

WebDAV: the resource is locked.

WebDAV: the request failed because a dependent request failed.

The server refuses to risk replaying the request (TLS 0-RTT).

The client must switch to a different protocol (e.g. TLS).

The server requires a conditional request to prevent lost updates.

Rate limit hit. Fix: slow down and respect the Retry-After header. Common on APIs and behind WAFs.

The headers (often a huge Cookie) exceed the server limit.

Blocked for legal reasons (censorship, DMCA, GDPR).

A generic server crash. Causes: an unhandled exception, PHP fatal error, bad .htaccess. Fix: check the server error log — the real cause is there, not in the browser.

The server does not support the functionality to fulfil the request (unknown method).

A gateway/proxy got an invalid response from the upstream server. Causes: the backend (PHP-FPM/Node) is down or crashed. Fix: restart/scale the upstream, check its logs.

The server is temporarily overloaded or in maintenance. Honour the Retry-After header. Fix: scale up, fix the crash loop, or finish maintenance.

A gateway did not get a response from the upstream in time. Causes: a slow query/script. Fix: speed up the backend or raise the proxy timeout.

The server does not support the HTTP version used.

A content-negotiation configuration error on the server.

WebDAV: the server is out of space to complete the request.

WebDAV: an infinite loop was detected processing the request.

Further extensions to the request are required.

You must authenticate to gain network access — captive portals (hotel/airport WiFi) return this.