Use HTTP error codes to choose the next diagnostic step

A response code is evidence, not the whole incident

HTTP error codes describe the result of a particular request. A 4xx response points toward a request or access problem; a 5xx response indicates a server-side failure in fulfilling that request. The exact code, headers, response body, and request context determine the useful next action.

First separate an HTTP response from a DNS, connection, or TLS failure. If the client never receives an HTTP status, a table of HTTP codes cannot explain the entire problem. Preserve the error message and troubleshoot the stage that actually failed.

Capture a small, inspectable response

curl --silent --show-error --max-time 20 --dump-header response-headers.txt --output response-body.html https://example.com/

This public example saves headers and body separately. Use a permitted target and inspect the files rather than treating a nonempty body as success. On Windows, use curl.exe when required to avoid a shell alias.

For an authenticated API, redact credentials, cookies, tokens, personal data, and sensitive query parameters before sharing a trace. Keep the method, endpoint path, timestamp, and a safe correlation identifier. Never paste a complete authorization header into a public support post.

Match common codes to a concrete check

A status code can be generated by an intermediary rather than the application you intended to reach. Read response headers and the body for context. Avoid inferring the exact origin of a failure solely from a branded error page.

Do not retry every failure the same way

Correct a malformed request before sending it again. Restore valid authorization through the documented process instead of rotating identities or routes. For rate limits, reduce the request rate and follow the provider's delay guidance rather than trying to bypass the limit.

A retry can duplicate a state-changing operation if the first attempt succeeded but its response was lost. Review the API's idempotency guarantees and supported keys before retrying a POST. Use a bounded attempt count and backoff only where retrying is appropriate.

Distinguish accepted work from completed work

Not every 2xx response means the requested business task is finished. HTTP 202 indicates acceptance for processing, while the eventual task can still fail. Follow the documented job or status resource instead of immediately collecting an output that does not yet exist.

The HTTP 202 guide provides a separate job-state walkthrough. Keep HTTP-level success, job completion, and usable output as different checks. That separation is especially important in crawl and data-processing workflows.

For the boundary between DNS, transport, TLS and HTTP, read the Internet Protocol guide.

Work through a controlled correction

Imagine an authorized API request returns 415 because the client sends a JSON body without the documented media type. Save the response, compare the request with the current API contract, correct the header and body pairing, then repeat one bounded request.

If the request is accepted, inspect the actual response and any task state before expanding the workload. Record the changed field and outcome. A clean incident note shows what was wrong, what changed, and how the original task was verified.

FAQ and next action

Can a 200 response contain the wrong page? Yes. An application can return an unexpected screen or content with a successful HTTP status. Validate the required fields and body.

Where should I continue? Use the existing curl POST guide for request-body setup or the download guide for file validation. Use Arcvenza's documented workflow only for supported operations and permitted targets.

Technical references

MDN: HTTP response status codes · RFC 9110: HTTP semantics · curl command manual

MDN: HTTP response status codes · RFC 9110: HTTP semantics · curl command manual