curl -I
curl -I (or curl -sI) sends a request and prints the raw
response headers -- fast, universal, already installed almost everywhere. It is a fine first look
at what a server actually sent. What it does not do is tell you which of those headers, in
combination, form a well-documented misconfiguration: a Vary: * that makes the whole
response uncacheable forever, or a Cache-Control: public alongside a
Set-Cookie header that lets a shared cache leak one visitor's cookie to the next.
Reading raw headers and knowing what they mean together are two different skills.
This tool sends the exact same single request curl -I would, then
classifies the response's caching headers into seven named, RFC-backed patterns and states in
plain English why each one matters and which header proves it. It does not replace
curl -- the CLI here uses the same one HTTP request either tool would send -- it
automates the reading a person would otherwise have to do by eye, every time.
| Question | Where to answer it |
|---|---|
| I just want to see the raw response headers for a URL, quickly. | curl -I -- that quick raw look is exactly its job. |
| I want to know whether this response's caching headers have a named misconfiguration, and why it matters. | This checker -- names the pattern (Vary: *, a public + Set-Cookie leak, and five more) instead of leaving you to notice it in raw output. |
| I want this checked automatically on every deploy, with a non-zero exit code on a real problem. | This checker's CLI -- node check.mjs <url> --json exits non-zero on a danger-severity finding, wireable into any CI step alongside your existing curl-based smoke tests. |
I'd rather not learn all seven RFC-backed patterns from memory to read curl output myself. |
This checker -- paste the CLI's JSON into the browser report and get the plain-English findings without already knowing the rules. |
Neither tool replaces the other, and in practice most people use both: curl -I for a
fast raw look at one response, this tool for the recurring, automatable question of whether that
response's caching headers actually do what they look like they do.
node check.mjs https://example.com --jsonSame one request curl -I https://example.com would send. Paste the JSON into the checker for the plain-English report.
Different jobs, and most people who use this tool also still reach for curl. curl -I (or curl -sI) shows you the raw response headers for a URL -- fast, universal, and already installed almost everywhere. It does not tell you what those headers mean together: whether a Vary: * silently makes the whole response uncacheable, or whether a Cache-Control: public alongside a Set-Cookie header is a shared-cache cookie leak waiting to happen. This tool reads the same headers curl would show you and names the specific, well-documented pattern -- so you don't have to already know the RFC details to notice the problem.
If you already know every pattern this tool checks -- Vary: *, public plus Set-Cookie, no-store beside a leftover max-age, Expires silently overridden by Cache-Control, a stale Expires, a weak ETag on a range-capable response, a static asset with no caching headers -- curl -I plus your own judgement is enough. This tool exists for the times you don't want to re-derive all seven from memory on every response, or when you want the same checks wired into CI as a non-zero exit code rather than a person reading terminal output each time.
No -- exactly one. The CLI (check.mjs) sends the same single GET request curl -I would send to the URL you name, reads the response headers, and classifies them locally. It does not crawl the site, does not send a second request to compare against, and does not go through any server this portfolio operates -- the request goes straight from your machine to the URL you choose, same as curl.
No. The CLI's request goes directly from your machine to the URL you name, exactly like curl. The browser report viewer only parses JSON you paste into it yourself, locally in your browser -- nothing about the target, the headers, or the report is sent anywhere. The only thing stored is an anonymous local count of which features were used, with no target URLs or header values in it.
Chasing a specific symptom instead? Why isn't my CDN caching this? walks the six response-header reasons in the order worth checking them.