Read the response around the document

HTTP response headers accompany a resource but are not part of the page's visible prose. They can describe the content type, cache handling, and other behaviour. A browser's network panel or an HTTP client can show these fields alongside the response status and body.

Record the exact request address and any redirects before interpreting a header. A redirect response and the final document may contain different fields. A cached response may also differ from a fresh request. Without that context, two observations can appear contradictory even when each accurately describes a different response.

Keep evidence small and useful

Store the fields relevant to the question being investigated rather than copying every byte into an agent prompt. Avoid retaining authentication material or unrelated personal data. Separate the observed value from the conclusion you draw from it, and attach the observation time and source URL.

Header names are case-insensitive, so a comparison should not treat capitalisation alone as a behavioural difference. Repeated fields need careful handling because their meaning depends on the particular header. Use a maintained HTTP parser instead of inventing a general splitting rule for every field.

Compare with the rendered page

A response can be technically successful while its document is unhelpful, and a visually friendly error page can still carry a missing-resource status. Review the response and the rendered experience together when deciding whether a link or page behaviour needs attention.