Response Caching Helpers

## Two places a validator can come from A validator is a short token the server sends with a response, which the client echoes back on its next request so the server can answer "unchanged" instead of resending. Frameworks let that token come from two very different places, and the difference decides what the feature is worth. **Source one: the rendered body.** A helper late in the chain buffers the outgoing body, hashes it, and writes the digest as the validator. If the request carried the same token, the framework discards the body and returns an empty 304 instead. No cooperation from the handler is needed - this is why it is usually a one-line switch. **Source two: the resource's own state.** The handler (or a hook ahead of it) reads something cheap that identifies the current version - a monotonically increasing revision column, a last-modified timestamp, a digest stored when the record was written, or a composite of those for a page built from several records. It compares that with the token in the request and, on a match, returns 304 immediately. ## What each one actually saves | | Body hash | Resource version | |---|---|---| | Computed | after rendering | before rendering | | Needs handler cooperation | no | yes | | Saves payload bytes | yes | yes | | Saves queries and rendering | **no** | **yes** | | Changes when | any byte changes | the tracked state changes | | Main failure mode | flapping validators | a stale or incomplete version source | The row that matters is the third one. A body-hash validator is computed from the thing whose production was the expensive part, so the cost is already sunk when the comparison happens. On a service whose responses are small but whose handlers are slow, this saves close to nothing; on a service that ships large payloads to clients on poor links, it saves a great deal. Both facts are true at once, and being able to say which case you are in is the answer interviewers want. ## Why the automatic validator flaps A hash over the rendered bytes changes whenever **any** byte changes, including bytes nobody cares about. Common sources of churn: - a generated timestamp, request identifier or anti-forgery token embedded in the body; - serialization that does not fix the ordering of keys or collection members; - a rendering layer that varies whitespace between runs; - content assembled from a source whose formatting differs per process. Each of these turns a resource that did not change into a resource that appears to change on every request, and every conditional request then gets a full response. The symptom is a validator that never matches; the cause is almost never the caching code. The mirror-image failure belongs to the version validator: it is only as good as the state it is derived from. If the page is assembled from a record plus its related records plus a locale bundle, and the version only tracks the main record, the server will confidently answer 304 to a client whose copy is stale in the parts the version does not cover. A version validator has to cover **everything that varies the representation**, including the negotiated format and language, or it will lie. ## Where the helper sits in the chain Placement follows directly from the source. A body-hash helper has to sit where the complete body is available, which is late - and it must buffer the body, because you cannot hash bytes you have already streamed out. That has its own cost: buffering a large or streamed response to hash it can be worse than sending it. Many frameworks therefore skip the automatic validator for streamed responses entirely, and that skip is silent. A version-based check sits at the very front, where it can short-circuit. In practice that means the handler's first few lines read the version, compare, and return early - or a hook ahead of the handler does it, given a route-supplied function that knows how to look the version up. ## Choosing 1. **Default to the automatic body hash** when responses are payload-heavy, the handler is cheap, and the body is stable byte-for-byte. It costs one line and removes the payload from repeat responses. 2. **Invest in a version validator** when the handler is the expensive part - several queries, a heavy render, a fan-out to other services. This is the only variant that removes server work. 3. **Do both** where it fits: short-circuit on the version when you have one, and let the body hash cover the responses where you do not. 4. **Turn the automatic helper off** on routes whose bodies are known to churn on every request; a validator that never matches is pure overhead - you pay the hash and always send the body anyway.