LEARN. PRACTICE. GROW.An HTTP status belongs to a hop
A request can have several compatible outcomes as it crosses intermediaries. In the /revalidate group, the first read stores validated-body with a known ETag. After expiry, the proxy contacts the origin with a validator, receives 304 and delivers 200 with the stored body to the client. A useful comparison aligns resource, time, cache state and validator. It does not require every status to match. In a fictional handover, the origin team and APS can present correct captures from different hops. Ask for the complete sequence before blaming the network for losing a body that the 304 response should not carry.
Separate HTTP freshness from business freshness
In a calculation exercise, consider a 60-second lifetime and an already-calculated current_age of 45 seconds, with no other constraints. Fifteen seconds remain before it stops being fresh. This calculation does not determine when a price was computed or whether the latest positions file has arrived. The lab does not measure data age in a financial application. For that context, add version, production time and the operation requirement to technical evidence. A newly validated response may reflect an origin whose business processing is delayed. Do not replace functional validation with a TTL value or successful conditional exchange.
Observe the failure that caching can hide
The /stale and /strict endpoints start with last-known-value and a short lifetime. After expiry, the fictional origin enters failure mode and returns 503. The first endpoint allows expired content under this condition; the second retains the experiment strict policy. The client observes 200 STALE on the first and 503 on the second. Also inspect upstream in the log: 200 is not evidence of origin recovery. This comparison separates availability of an earlier representation from availability of current processing. It does not make serving expired content a universal choice; define when the operation accepts that compromise.
Decide per operation with exit criteria
In a fictional case, an informational dashboard accepts delayed values, while a settlement decision requires current values. Define two worksheet rows: permitted degraded viewing and a decision suspended until sufficient evidence exists. Record who accepts degradation, how delay is communicated and which observation allows exit from that state. Increasing the number of 200 responses does not automatically meet these criteria. The team may consider an approved alternative source but must validate equivalence and reconciliation. This lesson does not define a bank internal standards; it provides a negotiation exercise between support, the application team and a functional owner.
Practice the English handover
Set aside fifteen minutes to write a short English update using lab results. Use the sentence Cached reads remain available; origin recovery is not confirmed and add the affected resource, observed version, functional restriction and next update point. A colleague takes the business-owner role and asks whether the operation can resume. Respond with the acceptance criterion instead of leaving the other person to interpret STALE alone. Then identify which information is observed and which is a hypothesis. This is a proposed learner exercise; it does not represent a human workshop already performed during this review.
Close with recovery evidence
The final worksheet should let another team repeat the reasoning: identify the operation, expected body, required version, per-hop statuses and an authorized read result. If cache policy changed, include validation after rollback and treatment of earlier entries. A diagnostic bypass read does not replace the ordinary path. Finish with three separate conclusions: what works, what remains degraded and what was not tested. TLS, browser caches, authentication, concurrency and real data remain outside the lab scope. Retain those limitations when presenting the result to a production team.
CACHE RECOVERY WORKSHEET / GRELHA DE RECUPERACAO
Operation / Operacao:
Expected resource and variant / Recurso e variante esperados:
Required business version and freshness / Versao e atualidade necessarias:
Client status, cache state, upstream status / Estados por salto:
Observed body version / Versao observada:
Permitted degraded use / Uso degradado permitido:
Blocked operation / Operacao bloqueada:
Owner and next update / Responsavel e proxima atualizacao:
Ordinary-path recovery evidence / Evidencia de retoma no percurso normal:
Rollback and previous entries / Reversao e entradas anteriores:
Remaining untested scope / Ambito ainda nao ensaiado:
The same origin 503 results in 200 STALE on one endpoint and 503 on another. Observed continuity depends on policy and permitted data use.
Common pitfalls
Closing the incident on the 200 rate, confusing TTL with price age or interpreting a bodyless 304 as truncation of the client response.
Related topics: The request and intended representation · Caching, variants, and validation · Diagnosis and time budgets
Recovery requires functional and technical evidence matching the operation; serving an older representation may provide only degraded continuity.
Reference: RFC 9111: HTTP Caching · BigSavant HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance