For a conditional GET, replace the stored body after a 200; reuse it after a 304. A 304 validates reuse rather than supplying replacement content. See MDN’s If-None-Match reference.
Stored response handling
This table is an editorial handling method, not an official GitHub recovery procedure.
| Saved state | Request validator | Response | Handling decision |
|---|---|---|---|
| Body and ETag | Saved ETag in If-None-Match | 200 | Replace body; save returned ETag if supplied. |
| Body and ETag | Saved ETag in If-None-Match | 304 | Reuse saved body. |
| ETag without body | Saved ETag in If-None-Match | 304 | Flag incomplete storage: nothing to reuse. |
Hypothetical saved ETag trace
Save body A and ETag "demo-a". Send If-None-Match: "demo-a". A hypothetical 304 retains A; a later hypothetical 200 with body B and ETag "demo-b" replaces both. These labels and outcomes are invented, not test results.
GitHub rate-limit boundaries
GitHub’s primary-rate-limit exemption requires both a returned 304 and correct authentication through an Authorization header. Do not extend that exemption to every request or every limit. GitHub also recommends webhooks over polling; when polling is necessary, honor any x-poll-interval header before polling that endpoint again. See GitHub REST API best practices.
Next implementation check
Review the stored body and validator together. Record endpoint-specific unknowns separately from observed behavior. Check replacement, reuse and missing-body handling without describing an unperformed test as successful. Validation also does not prove that later application work used current data.
Source check: supplied GitHub Docs and MDN captures dated 2026-10-25 UTC; no live API test. Refresh the evidence when documentation changes or its validity window expires. The excerpts do not establish behavior for your particular endpoint.
