Cache killer?

[ptbrown]

What's this about Clacks effecting no-cache? That doesn't sound right. Well, actually it does. But that could put the kibosh on actual use of the Overhead as servers would avoid it on static content.

Better to say that duplicate Overhead messages MUST be merged. That's what I'm doing in the browser extension.

[madbobmcjim]

I think we (well, I) need a bit of a better understanding of the use cases.
The section can certainly be made more cache friendly, I'll send you a modification shortly.

[ptbrown]

You're right. A better understanding is needed.

HTTP endpoints are gateways to the Clacks network. It's not correct then to think of the Internet computers as being the endpoints of Clacks messages. (If so, it is only by emulating a Tower.) As such the HTTP request made by a gateway will presumably be constructed with appropriate cache control.

Repeated messages and multicast messages are not foreign to the Clacks network as a tower may receive a turn-around message more than or may receive a go-ahead message from two different towers if there are multiple paths to it. (A message from Lancre may arrive in Ankh-Morpork via Sto Lat or Pseudopolis. Additionally, we can expect that sending a particular Overhead message that demands a response to a single tower more than once will get the same message back both times. Or, at least, the second response will be identical to the first with the appended data "Now bugger off!" But that's an implementation detail of Clacks that need not be replicated in HTTP.

[Krinkle]

Using a Vary header might help mitigate concerns about cacheability.