HTTP headers are small pieces of metadata that travel with a web response, but they often explain behavior that is otherwise difficult to see. When a page caches unexpectedly, returns the wrong content type, or appears to be missing a security control, the headers can…

HTTP headers are small pieces of metadata that travel with a web response, but they often explain behavior that is otherwise difficult to see. When a page caches unexpectedly, returns the wrong content type, or appears to be missing a security control, the headers can reveal what the server actually told the client.

What WebLens shows

The WebLens HTTP Headers tool requests the target and displays the response headers it receives, together with the HTTP status and a header count. It is useful when you need to inspect a production endpoint without opening browser developer tools or server configuration.

Headers worth looking at first

Content-Type tells clients what kind of content they received. Cache-Control describes caching behavior and can explain why browsers or CDNs retain content. Strict-Transport-Security tells supporting browsers to use HTTPS for a configured period. Content-Security-Policy can restrict which resources a browser may load. Location is important on redirects because it identifies the next destination.

These are policy signals, not a complete security audit. A header can exist while still being configured too broadly or too narrowly for the application’s needs.

A reliable inspection workflow

  1. Run the WebLens HTTP Headers Checker for the exact URL involved.
  2. Record the HTTP status before interpreting individual headers.
  3. Look for content type, caching, redirect, and security policy headers relevant to the issue.
  4. Compare the public response with the configuration you expect from the origin, CDN, or reverse proxy.
  5. Recheck after changes because intermediate caches can preserve an older response.

Example: a caching problem

Imagine a developer publishes a new stylesheet but visitors continue receiving the old version. The headers may show a long cache lifetime. That does not automatically mean the cache is wrong; long-lived static assets are often intentional. The real question is whether the asset URL changes when the file changes, or whether cache invalidation is configured correctly.

Example: a redirect problem

A homepage may appear fine while an API client reports repeated redirects. Inspecting the status and Location header can reveal that one hostname redirects to another, which then redirects back through a different scheme or host. The header evidence makes the loop easier to isolate.

What headers cannot tell you

Response headers are only one part of an HTTP exchange. They do not reveal server-side application code, database queries, browser execution, or every header generated by an upstream system that was not present on the final response. They also do not prove that a security policy is perfectly configured.

Why the same URL can produce different headers

CDNs, cookies, geographic routing, authentication, A/B testing, proxies, and application logic can alter responses. WebLens sends its own request, so its response can differ from what a logged-in browser receives. Treat the result as evidence from one public request path.

Need to see what a server is actually sending? Use the WebLens HTTP Headers Checker and inspect the response before changing your web stack.

Headers and layers: where to look next

A header only has meaning in the context of the response that carries it. If a CDN adds a cache header while the origin adds another policy, the public result may reflect the edge rather than the application server. Likewise, a reverse proxy can terminate TLS and generate headers before forwarding the request. When a value differs from your configuration, identify which layer actually produced the public response.

For caching issues, compare the asset URL, Cache-Control directives, and any CDN behavior. For security policies, inspect the complete value rather than checking only whether a header exists. For redirects, follow the Location chain deliberately and confirm that the final hostname and scheme match the intended architecture.

A practical before-and-after check

When you change a response header, save the old result first. Apply the configuration, purge any intended cache, then run WebLens again against the same URL. This gives you a simple external record of whether the public response changed. If it did not, the stale value may be coming from an upstream cache or a different server than the one you edited.