HTTP Header Inspector

What it does

HTTP Header Inspector sends a request to a URL and shows the full response headers the server returns, along with any redirect chain leading to the final page. It surfaces caching directives, content type, compression, cookies, and the security-relevant headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) that determine how browsers protect users on your site. Pair this with SSL Certificate Checker to confirm the cert is valid before judging HSTS, and DNS Lookup to see how the URL resolves.

When to use it

• Verifying that a CDN or origin is sending the cache-control headers you configured, and that your max-age is being respected.
• Auditing a site's security posture by checking which protective headers are present, missing, or misconfigured.
• Tracing a redirect chain that's adding latency to first-byte time — every 301 or 302 hop is a round trip you can often remove. If latency is also high, run a Speed Test to rule out the local connection.
• Confirming that a deployment actually shipped the new Content-Security-Policy and didn't accidentally revert to a permissive default.
• Diagnosing why a browser is rendering "text/plain" instead of HTML by reading the Content-Type header.

How to read the results

The status line tells you whether the URL succeeded (200), redirected (301/302/308), required authentication (401), was forbidden (403), or errored (5xx). Cache-Control with a max-age governs how long browsers and intermediaries reuse the response. Strict-Transport-Security (HSTS) tells browsers to enforce HTTPS for a stated duration — only meaningful if your TLS chain is healthy, which you can confirm with SSL Certificate Checker. Content-Security-Policy restricts where scripts, styles, and other resources can load from. Set-Cookie attributes (Secure, HttpOnly, SameSite) determine cookie safety.

Common mistakes

• Assuming a redirect chain ending in 200 means the original URL is healthy — every hop adds latency and SEO sites should fix the source link.
• Adding HSTS with a long max-age and the preload flag before confirming HTTPS works perfectly on every subdomain — verify each one with SSL Certificate Checker first; once preloaded, the policy is hard to undo.
• Setting Cache-Control: no-cache on every response when you actually want immutable static asset caching, hurting performance.
• Treating the absence of a Server header as a vulnerability; hiding the banner is good practice, not a finding.

# curl — JSON response (default)
curl https://internettimes.com:80/api/v1/http-headers/example.com \
  -H "Authorization: Bearer YOUR_API_KEY"

# Markdown response — ingest-friendly for agents
curl "https://internettimes.com:80/api/v1/http-headers/example.com?format=md" \
  -H "Authorization: Bearer YOUR_API_KEY"