HTTP Response Headers Explained: Security, Caching and Redirects
HTTP headers describe a response's content, caching, redirects, and selected browser security controls.
How it works
301, 302, 307, and 308 redirects have different semantics. Server, content-type, cache-control, expires, etag, and last-modified help diagnose responses. HSTS, CSP, and X-Frame-Options need context: one missing header is not automatically a vulnerability.
What an HTTP response tells you
An HTTP response starts with a status code and headers that describe the result. A 200 usually means a successful response; 4xx codes usually describe a client-side request problem; 5xx codes indicate a server-side failure. The result only describes that request path, at that time, from that network context.
Redirects use 3xx status codes. 301 and 308 communicate permanent moves, while 302 and 307 are temporary redirects; 303 is commonly used to direct a follow-up request to another URL. The exact method-preservation behavior differs, which matters for application flows even though ordinary browser navigation often looks similar. A redirect chain should be short, intentional, and end at the expected canonical HTTPS URL.
The Server, Content-Type, and Content-Length headers provide basic response context. They can help explain whether a route returned HTML, JSON, a download, or an error page. They should not be treated as a complete inventory of the underlying software or a security assessment.
Caching and browser policy headers
Cache-Control, Expires, ETag, and Last-Modified influence how browsers and intermediaries reuse content. Cache-Control is generally the most direct modern policy; ETag and Last-Modified support conditional requests. A surprising old response may come from a browser, CDN, or proxy cache rather than the origin server.
HSTS asks browsers to prefer HTTPS for a host after they have received the policy. Content-Security-Policy (CSP) constrains resource loading and script behavior. X-Frame-Options helps control framing, X-Content-Type-Options can prevent MIME sniffing, and Referrer-Policy controls referrer information in outgoing requests. Missing one header is not automatically a vulnerability: the right setting depends on an application's behavior and its other controls.
Header values can differ by path, cookie state, authentication, language, CDN edge, and client location. Compare like with like. A public homepage response is not proof of what an authenticated dashboard, API, or regional edge returns.
How the checker makes its request
The HTTP Headers & Redirect Checker starts with a HEAD request where possible because it can return headers without downloading a full body. Some servers do not support HEAD correctly, so it may use a small GET fallback. It follows a bounded redirect chain manually and checks each public target before connecting.
This is a diagnostic request, not a browser simulation or vulnerability scanner. It does not send cookies or authorization data, submit forms, crawl a site, or test private and reserved addresses. A result can still differ from a normal browser session because CDNs, bot controls, and content negotiation may respond differently.
When a chain is unexpected, write down every hop: starting URL, status, Location target, final URL, and final status. A loop commonly occurs when an origin forces HTTP while a proxy forces HTTPS, or when www and apex rules disagree. Fix the authoritative redirect rules rather than adding more redirects around the symptom.
Practical examples and next checks
A clean move from http://example.com to https://example.com/ might show one permanent redirect followed by a 200 response. Repeated alternation between www and non-www is a configuration loop. A 302 from a signed-in application can be normal, but it should be interpreted with the missing session context in mind.
Use the checker to understand status, selected headers, and public redirects. Check the TLS certificate if the final host is HTTPS, query DNS if a hostname resolves unexpectedly, and compare public resolvers if a recent DNS change appears inconsistent. Do not use the absence of a header as a verdict on site safety.
When troubleshooting a migration, test both the old and intended URLs without a logged-in session, then verify that each hop uses the expected scheme and hostname. A permanent redirect is appropriate only when the move is genuinely durable; temporary responses are useful during a controlled transition. If caching appears to preserve an old destination, inspect Cache-Control and CDN rules as well as the redirect itself. The checker gives a bounded public view, so reproduce important behavior in the relevant browser, region, and authenticated state before changing production rules.
Practical guidance
- Review the entered URL, each redirect hop, and the final URL together.
- Compare cache headers before assuming an old response came from the origin.
- Check TLS and DNS when a public response is unexpected.
Common question
What does the checker do? It uses HEAD first, may use a small GET fallback, follows a bounded public redirect chain, and does not expose cookies, authorization data, submit forms, or scan for vulnerabilities.