VERIFYFIRST // http-response
A status code — You requested the URL and got 200.

WHAT IT CAPTURES
  That something on the path was willing to answer, and considered the answer complete.

WHAT IT CANNOT SEE
  - Which layer answered: origin, CDN, proxy, or your own local cache.
  - Whether the body is correct, or even the right document.
  - Staleness. A cached copy returns 200 forever.
  - Redirects, so the URL that answered may not be the URL you asked for.

KNOWN FAILURES (4)

  NS-007  Heuristic HTML caching makes a completed deploy invisible to its author
    reads as   The old page is on screen after deploy. Conclusion drawn: the deploy failed.
    actually   Origin serves the new bytes. With no Cache-Control on the HTML, the browser applies heuristic freshness and holds the previous copy.
    check      Hash the served bytes from a client that has never requested it: curl -s URL | md5sum, compared to the file on disk.

  NS-020  S3 sends 200 OK before it knows whether the upload completed
    reads as   CompleteMultipartUpload returns HTTP 200. Conclusion drawn: the object is assembled and present.
    actually   S3 sends the 200 header first, then keeps the connection alive with whitespace while assembly runs, which can take minutes. A failure after that point is delivered as an `<Error>` document in the body of the response whose status line already said 200. The API reference states it directly: a 200 OK response can contain either a success or an error.
    check      Parse the body even on 200 and look for an `<Error>` root element; or confirm independently with HeadObject and compare ContentLength and ETag against what was uploaded. Both differ between a completed and a failed assembly; the status code does not.

  NS-021  A batch write returns 200 while handing back the items it did not write
    reads as   BatchWriteItem returns HTTP 200 and the SDK raises no exception. Conclusion drawn: all 25 items were written.
    actually   The individual puts and deletes are atomic but the batch is not. Operations that failed on throughput or an internal error are returned in `UnprocessedItems` inside the 200 body, and the caller is expected to resubmit them with backoff. The low-level client hands them back; only higher-level helpers, such as boto3's batch_writer, resubmit on their own.
    check      Assert the map is empty rather than assuming it: `sum(len(v) for v in resp.get('UnprocessedItems', {}).values()) == 0`. It is 0 on a full write and non-zero whenever items were dropped.

  NS-022  A single-page app's catch-all rewrite answers 200 for URLs that do not exist
    reads as   `curl -o /dev/null -w '%{http_code}' https://site/docs/pricing` returns 200. Conclusion drawn: the page exists and the link is good.
    actually   The host rewrites every unmatched path to index.html so the client-side router can handle it. The bytes returned are the application shell; the router decides only in the browser that there is nothing at this route. Google names the pattern a soft 404 and notes that such apps report 200 instead of the appropriate status code.
    check      Compare against a path that certainly does not exist: `curl -s $BASE/zzz-not-a-real-path | md5sum` and `curl -s $URL | md5sum`. Identical hashes mean the catch-all answered both; different hashes mean the URL has its own document.

---
Full registry: https://verifyfirst.dev/registry.json
This page:     https://verifyfirst.dev/http-response/
CC0-1.0. Every entry observed, none hypothetical.