How Can You Inspect HTTP Cache Headers from the Terminal?
From the earlier reference collection. Read the current software blog.
A header-only request can reveal cache directives and validators, helping diagnose freshness behavior without downloading a full response body.
Ask for headers deliberately
To inspect an HTTP response from a terminal, use a client that displays response headers. With curl, curl -sSI https://example.invalid/data.csv requests headers using a HEAD request and suppresses progress output. Some servers handle HEAD differently from GET, so if the result seems inconsistent with actual downloads, use a GET request while discarding the body: curl -sS -D - -o /dev/null https://example.invalid/data.csv. The domain here is illustrative.
Look for the status line as well as headers. A redirect, authorization failure, or server error changes what the cache information means.
Read freshness directives as a group
Headers such as Cache-Control, Expires, Date, and sometimes Age help describe how a response may be reused. max-age expresses a freshness lifetime, while directives such as no-cache and no-store have distinct meanings. Do not read a single directive in isolation: intermediaries, request headers, and the response status can affect observed behavior.
Compare two requests if you are investigating a changing result. Record the URL, time, status, and relevant headers. A response that carries an old-looking body may still be a client-side cache issue, while a fresh response could be coming from an intermediary. The headers provide clues, not a complete account of every layer.
Check validators and conditional requests
ETag and Last-Modified can act as validators. A client may send If-None-Match or If-Modified-Since on a later request to ask whether its stored representation remains current. A 304 Not Modified response indicates that the client can reuse its stored representation under the relevant protocol behavior; it does not include a replacement body.
For diagnosis, first capture a normal response, then make a conditional request using the observed validator. For example, curl can send If-None-Match with a value copied from the server's ETag. Preserve quoting carefully, and avoid assuming that every server implements validators correctly.
Turn observations into a reproducible note
Save headers to a file when comparing behavior over time, and redact tokens or private query parameters before sharing output. A compact note might say: “At 14:10 UTC, GET returned 200 with ETag X and Cache-Control Y; conditional request returned 304.” That is more useful than an unexplained terminal capture.
These checks help narrow down caching questions: whether a validator is present, whether a response claims a freshness period, and whether a conditional request is honored. They do not prove how every browser or proxy will cache the resource, so test at the layer where the problem occurs.