The task and original case
Model a conditional cache update without treating a304 response as a new body. Use deterministic response fixtures and a stored representation. The work sample should show how the body and its validator move together across an unchanged response and a changed response.
| Case element | Value or requirement |
|---|---|
| Inputs | Stored representation has ETag a. One response is 304; a later changed representation has ETag b and 200. |
| Build | A deterministic cache fixture and assertions for body/validator handling. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Begin with a stored body labelled version A and ETag a. Send its validator in an If-None-Match request in your model. The fixture first returns 304, then later returns 200 with a new body labelled version B and ETag b. Keep status, validator and body as separate state fields. Here a and b are model labels. Real HTTP field values must preserve the exact quoted entity tag, for example ETag: "a" and If-None-Match: "a", including a W/ prefix when supplied; never send a bare unquoted a as the wire validator.
MDN's caching guide explains validators and 304 responses. On304, retain the stored representation rather than attempting to parse a new success body. On200, replace the representation and store the new validator from that response. Keep the model focused on these two states; it is not a complete cache implementation covering freshness, Vary, authorization or every response header.
Sources[1]
Check the worked result
After 304, the displayed or returned body is still version A and the stored ETag remains a in this fixture. After the later 200, the body becomes version B and the stored ETag becomes b. The next conditional request should therefore carry b, not the obsolete a.
Check the body and validator together. Updating only the body or only the validator can produce a state that does not describe the response you actually stored.
Make the failure visible
Start with an empty cache and feed it 304. Your wrapper cannot reconstruct the missing representation; return a clear cache-state error or perform a declared recovery request. Also test 200 without an ETag: the new body may be usable, but the old validator must not remain attached to it. A generic response.ok check alone needs careful treatment because 304 is outside the 200–299 range.
Revise it and ask someone to reproduce it
Have a peer replay the fixture sequence and predict the stored state after each step. For revision two, add a second unchanged response after version B and confirm it retains B. Keep a small transition table in the README so a reviewer can reproduce both the normal path and the empty-cache failure.
- 304 never replaces the stored body with an empty response.
- 200 updates or clears the validator consistently with the new body.
- A304 received without a stored representation has an explicit failure path.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built an independent conditional-cache model that retains bodies on 304 and updates body-validator state together on 200.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.