Infrastructure & Networking
What is a response header?
A response header is a key-value pair included in an HTTP response that provides metadata about the response, communicating information about the content being returned, instructions for how the browser should handle it, security policies the browser should enforce, and directives for caching infrastructure. Response headers accompany every HTTP response, sent by web servers, CDNs, reverse proxies, and other HTTP infrastructure before the response body, providing clients with the context needed to correctly interpret, display, cache, and secure the returned content.
Where request headers flow from client to server, communicating client capabilities and preferences, response headers flow from server to client, communicating server decisions and content characteristics. Every HTTP response carries multiple response headers, a typical web page response includes headers specifying the content type, content length, caching behaviour, security policies, server identification, and various other metadata.
Response headers are one of the most powerful tools available to web server operators and developers for controlling browser behaviour, security headers instruct browsers to enforce content restrictions and HTTPS requirements, cache headers instruct browsers and CDNs how to cache responses, and redirect headers instruct browsers to navigate to different URLs. All of this behaviour modification happens through the response headers, the browser reads and obeys the headers as instructions from the server.
For redirect management the most critical response header is the Location header, which specifies the redirect destination URL in every 3xx redirect response. Beyond the Location header response headers on redirect responses control caching behaviour, determining how long browsers cache redirect destinations, and security, ensuring HTTPS is enforced throughout the redirect chain.
HTTP response structure
Understanding where headers fit in the HTTP response structure clarifies how they are transmitted and processed.
Status line: the first line of an HTTP/1.1 response, specifying the HTTP version, status code, and reason phrase:
Response headers: one header per line following the status line:
Empty line: a blank line separating headers from the response body.
Response body: the content of the response, HTML for web pages, JSON for API responses, binary data for files. For redirect responses the body is typically empty or contains a minimal HTML document with a meta refresh fallback.
In HTTP/2 and HTTP/3 response headers are binary-encoded using HPACK or QPACK compression, reducing header overhead through compression of repeated headers across multiple responses. The logical structure remains identical, the wire format changes but browsers interpret the same header names and values.
The Location header, redirect destination
The Location response header is the mechanism through which HTTP redirects communicate their destination, the most important response header in redirect management.
Location header syntax: the Location header contains an absolute URL specifying where the browser should navigate:
The Location header appears in 3xx redirect responses: 301 Moved Permanently, 302 Found, 307 Temporary Redirect, 308 Permanent Redirect: instructing the browser to make a new request to the specified URL. The browser reads the Location header, discards the current response, and immediately sends a new request to the Location URL.
Absolute vs relative Location URLs: the HTTP specification permits relative URLs in Location headers, resolved relative to the request URI. However best practice is to always use absolute URLs in Location headers, including the full scheme, domain, and path. Relative Location URLs create resolution ambiguity across different proxy implementations and HTTP client libraries. Redirect management platforms should always generate absolute URL Location headers.
Location header in different redirect types: all 3xx status codes use the Location header for their redirect destination. The status code communicates the permanence and method-handling semantics of the redirect, the Location header provides the destination regardless of which 3xx status code is used.
Essential response headers
The web’s core response headers communicate content characteristics and control browser behaviour.
Content-Type: specifies the media type of the response body and optionally its character encoding. Content-Type: text/html; charset=utf-8 indicates an HTML document encoded in UTF-8. Content-Type: application/json indicates JSON data. Content-Type: image/webp indicates a WebP image. Browsers use Content-Type to determine how to render or process the response body, incorrect Content-Type causes browsers to misinterpret responses.
For redirect responses Content-Type is typically not meaningful, the response body is empty or minimal. Including Content-Type: text/html on redirect responses is conventional but irrelevant since browsers do not render redirect response bodies.
Content-Length: specifies the size of the response body in bytes. Content-Length: 48291 indicates a 48,291-byte response body. Content-Length enables browsers to show download progress, allows connection reuse, the browser knows when the response is complete without the server closing the connection, and enables parallel resource loading. For empty redirect response bodies Content-Length: 0 is appropriate.
Date: the date and time at which the response was generated. Date: Wed, 15 Jan 2025 10:00:00 GMT. The Date header provides the reference timestamp for relative cache expiry calculations, max-age cache durations are calculated from the Date header value.
Server: identifies the web server software generating the response. Server: nginx/1.24.0 or Server: Apache/2.4.57. The Server header is optional and is often suppressed or obfuscated in production for security, revealing specific server software versions aids attackers in identifying version-specific vulnerabilities.
Cache-Control: the primary caching directive header, specifying how the response should be cached by browsers and CDNs. Covered extensively in the Cache-Control article. For redirect responses Cache-Control: max-age=86400 is a common configuration, caching the redirect for 24 hours at the browser while allowing CDNs to cache it. Cache-Control: no-store prevents caching entirely, appropriate for analytics-tracked redirects where every click should hit the redirect server.
ETag: a unique identifier for a specific version of the response, used for cache validation. ETag: "abc123def456". When a cached response expires the browser sends the ETag in an If-None-Match request header, the server returns 304 Not Modified if the content has not changed, or a full 200 OK response with new content and a new ETag if it has changed.
Last-Modified: the date and time the response content was last modified. Last-Modified: Tue, 14 Jan 2025 08:30:00 GMT. Used for date-based cache validation, browsers send If-Modified-Since requests with the Last-Modified value when cached responses expire.
Vary: specifies which request headers were used in selecting the response, informing caches to store separate cached versions for different values of the specified headers. Vary: Accept-Encoding tells CDNs to cache separate compressed and uncompressed versions. Vary: Accept-Language tells CDNs to cache separate language variants. Vary: * prevents shared caching entirely.
Security response headers
Security response headers are instructions from servers to browsers, enforcing security policies that protect users from various attack categories.
Strict-Transport-Security, HSTS: instructs browsers to always use HTTPS for the domain, eliminating HTTP connections and the window in which SSL stripping attacks could intercept connections. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload specifies that browsers should use HTTPS for one year, including all subdomains, and that the domain should be submitted to the HSTS preload list.
HSTS is one of the most important security headers for redirect management, it ensures browsers enforce HTTPS without going through the HTTP-to-HTTPS redirect on subsequent visits. After a browser receives an HSTS header for a domain it automatically upgrades HTTP requests to HTTPS without sending any request to the HTTP address, eliminating the redirect hop and closing the SSL stripping vulnerability window.
Content-Security-Policy, CSP: defines allowed sources for content loaded by the page, scripts, stylesheets, images, fonts, frames, and other resources. Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com restricts scripts to the same origin and a specific CDN. CSP prevents cross-site scripting, XSS, attacks by blocking scripts from unauthorised sources. For redirect responses CSP is typically not meaningful, the redirect response body is not rendered.
X-Frame-Options: controls whether the page can be embedded in iframes. X-Frame-Options: DENY prevents the page from being embedded in any frame. X-Frame-Options: SAMEORIGIN permits embedding only by pages on the same origin. Prevents clickjacking attacks, where attackers overlay invisible frames over legitimate pages to steal clicks.
X-Content-Type-Options: prevents browsers from MIME type sniffing, interpreting responses as a different content type than declared in Content-Type. X-Content-Type-Options: nosniff instructs browsers to strictly honour the Content-Type header. Prevents attacks where malicious content is served with an unexpected MIME type that some browsers might execute.
Referrer-Policy: controls what information is included in the Referer request header when navigating away from the page. Referrer-Policy: strict-origin-when-cross-origin sends the full URL as Referer for same-origin requests but only the origin, scheme and domain, for cross-origin requests. Referrer-Policy: no-referrer suppresses the Referer header entirely. Relevant for redirect management, when users follow a redirect the Referer header policy determines whether the destination sees the redirect source URL.
Permissions-Policy: formerly Feature-Policy, controls which browser features the page can use. Permissions-Policy: camera=(), microphone=(), geolocation=(self) disables camera and microphone access while allowing geolocation access only from the same origin.
Redirect-specific response headers
Several response headers have particular significance in the context of redirect responses, controlling redirect behaviour and downstream effects.
Location header and redirect chaining: the Location header in a redirect response may itself point to a URL that returns another redirect, creating a redirect chain. Browsers follow redirect chains automatically, making sequential requests until reaching a non-redirect response. Each hop in the chain adds latency: browsers must complete a full request-response cycle for each redirect before reaching the final destination.
Redirect management platforms should ensure Location headers point to final destinations, not to intermediate URLs that themselves redirect. Auditing redirect chains by following Location headers through multiple hops identifies unnecessary intermediate redirects that can be collapsed.
Cache-Control on redirect responses: the caching behaviour of redirects is determined by Cache-Control headers on the redirect response. 301 permanent redirects without explicit Cache-Control headers are cached indefinitely by browsers, the browser never re-requests the redirect source URL after following the initial redirect. This default permanent caching is appropriate for truly permanent redirects but problematic if redirect destinations change.
Adding Cache-Control: max-age=3600 to 301 responses limits browser caching to one hour, redirect destination changes propagate to browsers within an hour. Cache-Control: no-store prevents all redirect caching, every click re-requests the redirect source URL, appropriate for analytics tracking where every click must be counted.
Set-Cookie on redirect responses: cookies can be set in redirect responses, the browser stores the cookie and includes it in the follow-up request to the redirect destination. This mechanism is used in authentication flows, setting a session cookie in a redirect response before sending the browser to the authenticated destination. Cookie-setting redirects must ensure the cookie domain and path attributes are correctly configured for the destination.
Response headers in redirect management infrastructure
Redirect management platforms control response headers on redirect responses, configuring appropriate caching, security, and redirect destination headers for every redirect rule.
Consistent HSTS headers: redirect management platforms serving HTTPS traffic for connected domains should add HSTS headers to all HTTPS redirect responses, ensuring browsers enforce HTTPS for redirect source domains. A brand protection domain that redirects all traffic to a primary domain benefits from HSTS, subsequent visits skip the HTTP-to-HTTPS redirect entirely after the browser has stored the HSTS policy.
Cache-Control configuration per redirect rule: different redirect rules may warrant different cache durations. A permanent brand domain redirect, always pointing to the same primary domain, can use long cache durations, max-age=31536000. A campaign redirect with a destination that might change should use shorter cache durations, max-age=3600. A redirect used for click tracking should use no-store to ensure every click is counted. Redirect management platforms should allow per-rule cache control configuration.
Security header inheritance: redirect responses may benefit from security headers even though the response body is not rendered. HSTS headers on redirect responses are the most important, establishing HTTPS enforcement. Other security headers on redirect responses are typically not meaningful, they apply to rendered pages rather than redirect responses.
X-Robots-Tag for redirect source pages: the X-Robots-Tag HTTP response header provides the same directives as the HTML meta robots tag, including noindex, for non-HTML responses and for cases where HTML head insertion is not possible. A redirect source domain serving 301 redirects for all paths might add X-Robots-Tag: noindex to redirect responses, ensuring redirect source URLs are not indexed independently, though the 301 redirect itself is the primary signal for search engines to de-index the redirect source.
Common response header mistakes
Missing Content-Type header: omitting Content-Type on non-redirect responses causes browsers to attempt MIME type sniffing, potentially misinterpreting responses. Always include explicit Content-Type headers on all non-redirect responses.
Overly permissive CORS headers: Access-Control-Allow-Origin: * on all responses allows any origin to make cross-origin requests, appropriate for public APIs but inappropriate for authenticated endpoints. CORS headers should be scoped to specific permitted origins rather than using wildcards for sensitive resources.
Missing HSTS on HTTPS responses: not including Strict-Transport-Security on HTTPS responses leaves browsers without HSTS enforcement, subsequent visits may still attempt HTTP connections. Every HTTPS response should include an HSTS header, starting with short max-age values and progressively increasing as confidence in the HTTPS configuration grows.
Cache-Control inconsistency: inconsistent Cache-Control headers across related resources, some too aggressive, others not aggressive enough. Coordinated cache control across all resources on a page ensures consistent caching behaviour and avoids stale resource combinations.
Exposing server version in Server header: Server: Apache/2.4.57 reveals the specific server version to potential attackers. Production servers should suppress or genericise the Server header, Server: Apache or remove it entirely.