Read an HTTP response without rushing to declare an outage

Did the server deliver the expected document?

HTTP status describes request handling, not content accuracy. HTTP 200 may accompany an error-like page or the wrong document. Keep URL, method, client, time and redirects with the check.

1. Identify the request

   Record initial URL, GET or HEAD, useful headers and public or authenticated context, omitting secrets. Methods and clients may receive different responses.

2. Read the chain

   Record redirects and final destination. Separate permanent 301/308 and temporary 302/307; method preservation differs by code.

3. Open content

   Check title, MIME type and document. 202 accepts processing without completed results; 204 has no content; 304 concerns conditional cache validation.

4. Classify failures

   Separate 401/403, missing 404/410, 429 limits, server errors and DNS/TLS/timeouts. Read available Retry-After and space retries; retain uncertainty.

Situations and decisions

Typical situations for preparing a check. They do not describe completed assignments or actual observations.

Record to retain

• Initial and final URLs
• Method, client and date
• Statuses, MIME and received title
• Relevant body, restriction and retry decision

Official references

• IETF — HTTP Semantics
• IETF — Additional HTTP Status Codes
• Google — HTTP status codes
• MDN — 202 Accepted
• MDN — 304 Not Modified

Related source profiles

• data.gouv.fr
• data.europa.eu
• Wayback Machine

Related protocols

• Crawling and indexing audit
• Query a public API and retain a verifiable extract
• Maintain a reliable editorial corpus

Checks before reaching a conclusion

• Is the destination expected?
• Does content match?
• Is the method recorded?
• Are restriction and outage distinct?

A qualified response record separating status, content and availability.