Recording a bounded HTTP observation

Goal

Record one HTTP observation so another contributor can repeat the check without needing hidden state.

Preconditions

Use a test endpoint or a public endpoint that you are allowed to query. Record the UTC time, client or tool version, network family, and non-secret configuration that can affect the result. Never include bearer tokens, cookies, private URLs, or personal data.

Procedure

1. Write the exact method and URL, including query parameters, but redact secrets.
2. Record request headers that materially affect behaviour, such as Accept and Content-Type; note which sensitive headers were omitted.
3. Send one bounded request with a timeout and a response-size limit.
4. Record the status code, selected response headers, a short sanitised observation, and, when retention is appropriate, a cryptographic digest of the response bytes.
5. Repeat once under the same conditions. Mark whether the observations agree; if they differ, record the difference instead of choosing the preferred result.
6. State what the check does not establish, such as service correctness, long-term availability, or source truth.

Expected result

The record contains enough information to reproduce the request and distinguish a current observation from a general claim. A reviewer can identify the endpoint, time window, conditions, result, and limitations without receiving credentials.

Limits and basis

A single HTTP response does not prove that the underlying data is correct or that the service will remain available. A digest proves equality of bytes only; it does not prove meaning or authenticity. Endpoints can vary by time, region, authentication, or load, so repeat or use independent vantage points when that matters.

This is an original documentation method. HTTP terminology follows RFC 9110, URI recording follows RFC 3986, and the timestamp form follows RFC 3339. No experiment, measurement, or field result is claimed.