HTTP Status Codes: Debug the Request and Response

HTTP status codes describe the outcome of a request, but the useful diagnosis usually needs the method, headers, and response body too. A 200 response can contain an error page, and a redirect can change what the client sends next.

Start by retrieving the headers for an ordinary GET request:

curl -sS -D - -o /dev/null https://ronaldsvilcins.com/

The command displays the response headers and discards the body. It does not use -I, which would send a HEAD request and could exercise a different server path.

HTTP status codes belong to a particular request

The first digit groups the outcome:

The HTTP status reference is useful when a less familiar code appears. The method and resource still matter: a successful GET, a created object, and a completed deletion do not require identical responses.

Successful responses describe different results

200 OK commonly returns the requested representation. Check that representation when a page looks suspicious instead of treating the status as proof that its content is right.

201 Created reports creation of a resource, often with Location identifying it. 204 No Content reports success without a response body; client code should not blindly try to parse it as JSON.

206 Partial Content responds to a range request. Its Content-Range helps identify the bytes returned, which matters for resumable downloads and media seeking.

For a minimal API example, these are separate outcomes:

HTTP/1.1 201 Created
Location: /items/42
Content-Type: application/json
Content-Length: 9

{"id":42}

HTTP/1.1 204 No Content

These are illustrative response messages. The first has a JSON body; the second has none. HTTP versions other than HTTP/1.1 encode the exchange differently while preserving the status semantics.

Inspect a redirect before following it

The original GET command shows a redirect response without automatically following it. Look at the status and Location, then inspect the chain deliberately:

curl -sS -L -D - -o /dev/null https://www.ronaldsvilcins.com/

-L follows redirects, while -D - prints the response headers encountered. Several hops are different from a single canonical-host redirect even if both eventually show a page.

301 and 308 indicate permanent redirects; 302 and 307 are temporary. Method handling is the other important distinction. 307 and 308 preserve the request method, while 303 is normally used to direct the client to retrieve another resource after an operation.

Historical handling of POST with 301 and 302 can change the next request to GET. The redirect semantics in RFC 9110 explain why the status is more than an interchangeable way to supply a new URL.

I would inspect a form or API redirect with its real method in a controlled test. A successful redirected GET does not establish that a POST body will survive the same route.

Separate cache validation from navigation

304 Not Modified does not send the browser to a different article. It answers a conditional request using a cached representation.

A client can send an If-None-Match value previously received as an ETag. If the validator still matches under the request’s conditions, the server can respond with 304 instead of transferring the representation again.

The 304 reference explains this conditional exchange. Do not expect a new page body from that response or interpret it as a failed download.

The status alone also does not tell you how long the cached object is fresh. Check Cache-Control, validators, and the request headers together.

Read authentication and permission failures differently

400 Bad Request is a broad request problem. 401 Unauthorized indicates missing or invalid authentication credentials and is associated with an authentication challenge.

403 Forbidden means the server refuses the request. It does not prove that the user was authenticated successfully, and some services deliberately avoid revealing whether a protected resource exists.

404 Not Found means no current representation was found or that the server is unwilling to disclose one. For a missing public page, the helpful HTML should still carry that missing-resource status.

Check a path you expect not to exist:

curl -sS -o /dev/null -w '%{http_code}\n' https://ronaldsvilcins.com/status-code-example-missing-page/

Serving a “page not found” message with 200 sends a different signal to clients. Inspect both the returned document and its status when checking an error page.

Use the error that matches the operation

405 Method Not Allowed says the method is unsupported for the target resource. Check the Allow header rather than assuming the path is absent.

409 Conflict can describe an operation conflicting with the resource’s current state. 422 Unprocessable Content applies when the content is understood but its instructions cannot be processed.

429 Too Many Requests indicates rate limiting. A Retry-After header, when supplied, gives the client information about waiting. Repeating the same request more aggressively rarely helps investigate that response.

The correct client behavior depends on the operation. Retrying a read and repeating an operation that changes state deserve different care.

Find which server produced the failure

500 Internal Server Error is a generic server failure. 502 Bad Gateway and 504 Gateway Timeout describe gateway or proxy problems involving an upstream response or delay.

503 Service Unavailable can represent temporary overload or maintenance and may include Retry-After. The server-error definitions distinguish those cases.

A request might pass through a CDN, proxy, and application before it reaches a dependency. Find which component emitted the response before attributing every failure to the application code.

Treat informational responses as part of the exchange

100 Continue participates in sending a request body. 101 Switching Protocols indicates a protocol upgrade. 103 Early Hints can provide preliminary headers before the final response.

They are not substitutes for inspecting the final status. A tool may display an informational response and a later successful or failed response in the same exchange.

For a practical report, record the URL, method, final status, relevant headers, and the body actually returned. Those details give somebody else enough information to reproduce the problem without guessing what “the request failed” meant.

← Back to all articles