HTTP & Web Protocols

HTTP status codes are divided into five classes indicating the status of the request: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error).

401 Unauthorized indicates the request lacks valid authentication credentials, whereas 403 Forbidden indicates the server understands the client's identity but refuses to authorize access — a distinction that matters for both security auditing and how a client should react: 401 means "authenticate and retry," 403 means retrying with the same or different credentials won't help.

URLs (Uniform Resource Locators) specify the location of a resource: a protocol identifier (scheme), hostname, port, path, query parameters, and a fragment identifier. Query parameters must be percent-encoded to prevent special characters like spaces, ampersands, or question marks from breaking the request structure.

Beyond the URL and status line, HTTP messages carry headers that negotiate how the request and response are interpreted. The Content-Type header, and its underlying MIME type, tells the receiving side what kind of data the body contains — application/json, text/html, image/png, and so on — and the User-Agent header identifies the requesting client's software and platform, used for both analytics and serving platform-appropriate responses.

A common real-world task is diagnosing why an API request isn't behaving as expected. Start by checking the response status code with the HTTP Status Codes reference to confirm exactly what class of problem you're dealing with — a 4xx means fix the request, a 5xx means the problem is server-side.

Use the HTTP Header Analyzer to inspect the full request and response header set for security-relevant flags — missing CORS headers, absent cache-control directives, unexpected redirects — that a status code alone will not reveal.

If the URL itself looks suspicious or a query parameter is not being read correctly by the receiving service, use the URL Parser to break it into its scheme, host, path, query, and fragment components, and the URL Encoder/Decoder to confirm whether a parameter's special characters are correctly percent-encoded.

When a response's content type doesn't match what a client expects, cross-reference the Content-Type header's value against the MIME Type Lookup tool, and use the User-Agent Parser to confirm whether a service is serving different content based on the requesting client's declared platform.

Mistake: treating a 401 and a 403 as interchangeable "access denied" errors. A 401 response should prompt the client to (re)authenticate; a 403 means the identity is known but not permitted, so retrying with the same credentials, or even different valid ones for a different purpose, won't fix it. Handling them identically produces confusing retry loops.

Mistake: forgetting to percent-encode reserved characters in query parameter values. A parameter value containing an unencoded & or = will be parsed as if it started a new parameter, silently corrupting the query rather than raising an obvious error.

Troubleshooting: if a client reports a wrong or unexpected Content-Type, check whether the server is actually setting the header correctly or whether an intermediary such as a proxy or CDN is rewriting it — the MIME Type Lookup tool helps confirm what the value should be for a given file extension or expected format.

Troubleshooting: if two clients receive different responses from the same endpoint, check what the server does with the User-Agent header before assuming it's a caching or load-balancing issue — some APIs deliberately vary responses by declared client platform.

The current HTTP semantics, including status codes and headers, are defined by RFC 9110 (HTTP Semantics), which superseded the older RFC 7231 in 2022. HTTP/1.1 message syntax is defined by RFC 9112.

URI syntax, including the scheme/host/path/query/fragment structure this hub's URL Parser decomposes, is defined by RFC 3986, which also defines the percent-encoding rules for reserved characters.

Media types (MIME types) are registered and defined by RFC 6838 and maintained in the IANA Media Types registry, the authoritative source the MIME Type Lookup tool's reference data is drawn from.

CORS (Cross-Origin Resource Sharing), referenced in the header-analysis workflow above, is defined by the WHATWG Fetch standard rather than an IETF RFC.

If you're deciding whether a failed request is a client problem or a server problem, the status code class tells you immediately: 4xx means fix something about the request; 5xx means the problem is on the server and retrying the identical request won't help without a change on that end.

If you're building or debugging an API integration, JSON is by far the most common HTTP payload format in modern web APIs — see the JSON Workshop hub for formatting, validation, and conversion once you've confirmed the HTTP layer itself (status, headers, URL) is behaving correctly.

See the HTTP vs HTTPS comparison for when the added TLS handshake overhead of HTTPS is worth it versus plain HTTP — in practice, for anything public-facing today, it always is; the comparison covers the specific technical reasons why.