Sarah: Roger, a question for every web developer listening. You put no-cache on a response. Did you just tell the cache not to keep it?

Roger: Most people think so. Today we find out what you actually told it.

Roger: Quick housekeeping first. We're both synthetic voices, the music is generated too, and so is this show. The answers aren't invented, though. Every result you'll hear comes from a recorded Arxo run, and the facts and hashes for each one are in the show notes.

Sarah: Show notes. Got it.

Roger: This is Executable Knowledge: Cases.

Roger: Picture yourself setting cache headers for a site. Two directives look almost identical: no-cache and no-store. The rules come from RFC 9111, the HTTP caching standard. We loaded the two sections that matter into a small Arxo package, and we'll hand it five cases.

Sarah: What does a cache do by default?

Roger: Every response here is a plain GET that came back 200. By default the cache may keep it, and reuse it while it's fresh. The package even calls that rule reuse while fresh.

Sarah: Start easy, then.

Roger: The home page. Fresh, and sent without any directives.

Arxo answer: Result: true. Rule applied: Reuse While Fresh.

Sarah: A yes, from the rule you just named.

Roger: Now the news page. Also fresh. But it was sent with no-cache.

Sarah: And this is where I'd say: no-cache, so it isn't cached at all. Right?

Arxo answer: Result: false.

Roger: No reuse. So you're half right. But listen to how it lost.

Arxo answer: Reuse While Fresh is defeated by No Cache Needs Validation, by priority.

Sarah: So the reuse rule actually fired... and then lost?

Roger: It fired, and it was defeated by priority. And the rule that beat it says what it wants, right in its name.

Arxo answer: Rule applied: No Cache Needs Validation.

Sarah: No cache needs validation. So not never. Just not without asking first.

Roger: Exactly. Not without checking with the origin server first.

Sarah: So what happens when the cache does check?

Roger: That's the prices page. No-cache again, but this time the cache has validated the response with the origin.

Arxo answer: Result: true. Rule applied: Reuse After Validation.

Sarah: Back to yes.

Roger: And this one stacks two priorities. Listen.

Arxo answer: No Cache Needs Validation is defeated by Reuse After Validation, by priority. Reuse While Fresh is defeated by No Cache Needs Validation, by priority.

Roger: Validation beats no-cache. No-cache beats plain freshness. That's all no-cache ever said: reuse, but only after validation.

Sarah: Okay. Then what's no-store for?

Roger: A different kind of answer entirely. A proxy receives a private account page, sent with no-store. Nothing gets switched off here. The package sets up a prohibition, addressed to the proxy, from the day the response arrived.

Arxo answer: Prohibition: store response, on the proxy. Status: active.

Sarah: Active. So nothing has gone wrong yet.

Roger: Nothing yet. Last case. Same proxy, same page, and a record showing the proxy stored it anyway.

Arxo answer: Prohibition: store response, on the proxy. Status: violated.

Sarah: Violated.

Roger: Violated, and the answer names who was bound by it: the proxy. That's the difference in one line. No-cache is about when a cache may reuse a response. No-store makes storing it a breach.

Sarah: So no-cache means not without asking. And no-store means someone is on the hook.

Roger: Before you pick a directive, name the action you want to control: keeping the response, or using it again. Five cases, each with the rule that decided it. The facts, the full answers and the hashes are in the show notes.

Sarah: Next time: castling through a square nobody checked.

Roger: Both voices synthetic, every answer from a real run. This was Executable Knowledge: Cases, from Arxo.