HTTP Status Codes: Complete Reference for CDN Engineers

Beginner

HTTP status codes are the language that web servers speak to communicate the outcome of every request. For CDN engineers, understanding status codes goes beyond knowing that "200 means OK" and "404 means not found." Each status code has specific implications for caching behavior, origin shielding, error handling, and end-user experience. A CDN that mishandles a 301 redirect wastes cache space. A CDN that does not implement negative caching for 404 responses allows origin servers to be overwhelmed by requests for nonexistent resources. A CDN that caches 502 errors serves broken pages to thousands of users.

This reference covers all five categories of HTTP status codes, with particular attention to CDN-specific behavior, caching implications, and troubleshooting guidance for the codes you will encounter most frequently in production.

How Did HTTP Status Codes Originate?

The earliest version of HTTP — HTTP/0.9, designed by Tim Berners-Lee at CERN in 1991 — had no status codes at all. Requests were simple GET commands, and the server either returned the document or returned nothing. There was no way for the server to communicate why a request failed or that a resource had moved.

Status codes were introduced in HTTP/1.0 (RFC 1945, May 1996), which defined the three-digit code system and the five category classes (1xx through 5xx). HTTP/1.0 defined 16 status codes. HTTP/1.1 (RFC 2068, January 1997, revised as RFC 2616 in June 1999 and again as RFCs 7230-7235 in June 2014) expanded the list significantly, adding codes like 100 Continue, 206 Partial Content, 307 Temporary Redirect, and 409 Conflict.

The registry of HTTP status codes is maintained by IANA (Internet Assigned Numbers Authority) and continues to grow. Recent additions include 103 Early Hints (RFC 8297, December 2017), which allows servers to send preliminary headers before the final response, and 425 Too Early (RFC 8470, September 2018), which indicates that the server is unwilling to process a request that might be replayed (relevant to TLS 1.3 0-RTT).

What Are the Five Categories of HTTP Status Codes?

The first digit of the status code defines its category. Understanding these categories provides a framework for interpreting any status code, even unfamiliar ones.

1xx Informational

Informational responses indicate that the server has received the request and is continuing to process it. 100 Continue tells the client to proceed with sending the request body after an initial header-only request — useful when sending large uploads, as the client can check authorization before transmitting gigabytes of data. 103 Early Hints (RFC 8297) allows the server to send preliminary Link headers so the browser can begin preloading resources while the server prepares the final response. CDNs can generate 103 responses at the edge based on cached knowledge of a page's critical resources.

2xx Success

200 OK is the standard success response. CDNs cache 200 responses according to Cache-Control and Expires headers. 204 No Content indicates success with no response body — common for DELETE operations and CORS preflight responses. 206 Partial Content supports range requests for video streaming and large file downloads; CDNs must handle range requests carefully, either by forwarding them to the origin or by serving partial responses from a fully cached object.

3xx Redirection

301 Moved Permanently is the most important redirect for SEO and CDN caching. CDNs cache 301 redirects by default (Cloudflare caches them for 3 hours, others for up to 24 hours). Search engines transfer link equity to the new URL. Use 301 for permanent URL changes, domain migrations, and HTTPS enforcement.

302 Found indicates a temporary redirect. CDNs do not cache 302 redirects by default. The original URL should continue to be indexed by search engines. Use 302 for temporary maintenance redirects, A/B testing, or geolocation-based routing.

304 Not Modified is critical for CDN cache revalidation. When a cached object's TTL expires, the CDN sends a conditional request to the origin with If-Modified-Since (timestamp) or If-None-Match (ETag). If the origin responds with 304, the CDN knows its cached copy is still valid and refreshes the TTL without re-downloading the content. This saves bandwidth and reduces origin load dramatically — for a popular 5MB image, a 304 response saves 99.99% of the bandwidth compared to a fresh 200 response.

307 Temporary Redirect and 308 Permanent Redirect are method-preserving versions of 302 and 301 respectively. While 301/302 historically allowed browsers to change POST to GET when following the redirect (a violation of the original spec that became de facto behavior), 307/308 guarantee that the HTTP method is preserved. Use 308 when redirecting API endpoints that accept POST requests.

How Do Client Error Codes Affect CDN Behavior?

400 Bad Request indicates malformed syntax. CDNs pass this through without caching. Common causes include oversized headers, invalid URL encoding, or corrupted requests.

401 Unauthorized and 403 Forbidden indicate authentication and authorization failures respectively. CDNs generally do not cache these responses, as they depend on the requesting user's credentials. However, some CDN configurations cache 403 responses for known-blocked paths to reduce origin load.

404 Not Found is one of the most important codes for CDN configuration. Without negative caching, every request for a nonexistent resource passes through to the origin server. During a crawler storm or an attack targeting random URLs, this can overwhelm the origin. Best practice is to cache 404 responses for a short TTL (1-5 minutes) at the CDN edge — this is called negative caching and is explicitly permitted by RFC 7231 Section 6.1, which lists 404 as a cacheable status code.

410 Gone is a permanent 404 — it tells clients and search engines that the resource existed but has been intentionally removed and will not return. CDNs cache 410 responses by default. Use 410 instead of 404 when you deliberately remove content and want search engines to de-index it promptly.

429 Too Many Requests indicates rate limiting. CDNs often generate this code at the edge when enforcing rate limits, before the request ever reaches the origin. The response should include a Retry-After header indicating when the client can retry. CDNs do not cache 429 responses, as rate limiting is per-client.

What Do 5xx Server Errors Mean for CDN Operations?

500 Internal Server Error is the generic server-side failure. CDNs never cache 5xx responses by default — serving a cached error page to thousands of users would amplify an origin problem. Instead, CDNs implement stale-if-error behavior: if the origin returns a 5xx and the CDN has a stale (expired but not purged) cached version of the resource, it serves the stale version to users while continuing to retry the origin. The stale-if-error Cache-Control extension (RFC 5861) formalizes this behavior.

502 Bad Gateway means the CDN edge server (acting as a reverse proxy) received an invalid response from the origin server. This is one of the most common errors CDN engineers troubleshoot. Common causes include: origin server crashes or restarts; DNS resolution failures for the origin hostname; SSL/TLS handshake failures between CDN and origin (certificate mismatch, expired certificates, protocol version incompatibility); firewall rules blocking the CDN's IP addresses; or origin server responding with malformed HTTP.

503 Service Unavailable indicates the server is temporarily unable to handle requests, usually due to maintenance or overload. CDNs often generate 503 responses when all origin servers in a pool fail health checks. The Retry-After header should indicate expected recovery time. Some CDNs display custom error pages for 503 responses to provide a better user experience during outages.

504 Gateway Timeout means the CDN edge server did not receive a response from the origin within its configured timeout period. This typically indicates origin server overload, network connectivity issues between CDN and origin, or excessively slow application processing. CDN timeout configurations (typically 30-120 seconds for origin response) should be tuned based on the application's expected response time.

How Do CDN-Specific Headers Extend Status Code Information?

CDN providers add custom response headers that provide visibility into cache behavior beyond what standard HTTP status codes convey. These headers are essential for debugging and performance optimization.

Cloudflare uses Cf-Cache-Status with values including: HIT (served from edge cache), MISS (fetched from origin, now cached), EXPIRED (cache entry expired, revalidating), DYNAMIC (not eligible for caching), REVALIDATED (origin confirmed cache is still valid via 304), and BYPASS (cache intentionally skipped per rules).

AWS CloudFront uses X-Cache with values like Hit from cloudfront and Miss from cloudfront, supplemented by X-Amz-Cf-Pop (identifying the edge location) and X-Amz-Cf-Id (request trace ID for support debugging).

Fastly uses X-Cache with HIT or MISS, and X-Cache-Hits showing how many times the cached object has been served. The X-Served-By header identifies the specific cache node.

The standard Age header (RFC 7234) indicates how many seconds the response has been cached. An Age: 3600 header means the response was cached one hour ago. This is useful for understanding cache freshness and diagnosing TTL configuration issues.

How Should CDN Engineers Handle Redirect Chains?

Redirect chains — where URL A redirects to URL B, which redirects to URL C — are a common source of latency and a frequent troubleshooting target. Each redirect adds a full HTTP round trip. On a CDN edge 5ms from the user, three chained redirects add 30ms (three request-response cycles). When redirects involve the origin server, latency accumulates much faster.

Best practices include: limiting redirect chains to a maximum of two hops; configuring redirects at the CDN edge rather than the origin (reducing round-trip distance); using 301 for permanent redirects to enable browser and CDN caching; ensuring HTTPS redirects happen at the edge (http to https redirect should never reach the origin); and regularly auditing redirect chains using tools like curl -L -v or redirect-checking services.

CDNs like Cloudflare offer "edge redirects" or "redirect rules" that handle redirects entirely at the edge without involving the origin server. These execute in under 1ms and can handle millions of redirect rules efficiently — far better than origin-based redirect logic.

What Is Negative Caching and When Should You Use It?

Negative caching is the practice of caching error responses (typically 404 and 410) at the CDN edge for a short period. Without negative caching, every request for a nonexistent URL passes through to the origin, which must process the request, query its database or filesystem, determine the resource does not exist, and generate a 404 response. During crawler storms or enumeration attacks, this can create enormous origin load.

A negative cache TTL of 60-300 seconds (1-5 minutes) provides effective protection while ensuring that newly created resources become available quickly. Some CDNs also support negative caching of 403 responses (for blocked paths) and 410 responses (for deliberately removed content, often with longer TTLs).

Configure negative caching thoughtfully: too short and it provides insufficient protection; too long and it delays content availability when new resources are published at previously-404 URLs. The optimal TTL depends on your content publishing frequency and the expected attack surface.

How Do Status Codes Affect SEO and Search Engine Behavior?

Search engines interpret status codes as signals about content availability and URL structure. 200 responses are indexed normally. 301 redirects transfer approximately 100% of link equity to the target URL (Google confirmed in 2016 that 301s no longer lose PageRank). 302 redirects cause search engines to keep the original URL indexed — useful for temporary changes but problematic if used accidentally for permanent moves. 404 and 410 responses cause pages to be dropped from the index, with 410 signaling more urgently that de-indexing should happen quickly. 503 with a Retry-After header tells search engine crawlers to pause crawling temporarily without de-indexing content — the correct response during planned maintenance.

CDN engineers should coordinate with SEO teams to ensure that CDN-level redirects, error pages, and caching behaviors align with the site's SEO strategy. A common mistake is CDNs returning 200 status codes for custom error pages (soft 404s) — search engines index the error page content as if it were real content, polluting the site's index.