Disable caching

[nimec01]

This should fix #75

[Copilot]

Pull request overview

This PR attempts to address issue #75 (“Server won't run code”) by disabling HTTP caching for CodeWorld server responses, likely to prevent clients from using stale web assets after recent changes.

Changes:

• Import setHeader from Snap.Core.
• Add a disableCaching Snap action that sets Cache-Control.
• Invoke disableCaching in site around the main routing/static file handling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[patritzenfeld]

I want to add here what Cache-Control: no-cache actually does, because this option is badly named.

It does not completely disable caching, but instead makes the client validate that its cached resource is still up to date by asking the server. If the server thinks it is up to date, then the cached version is reused, otherwise it is invalidated.

[nimec01]

I want to add here what Cache-Control: no-cache actually does, because this option is badly named.

It does not completely disable caching, but instead makes the client validate that its cached resource is still up to date by asking the server. If the server thinks it is up to date, then the cached version is reused, otherwise it is invalidated.

I did read that on the MDN article. Are you suggesting changing the name of the disableCaching function?

[patritzenfeld]

No, I just want to document that fact if someone else reads this PR later.

And I'm also typing up something to discuss on that point right now.

[patritzenfeld]

I'm not really satisfied with this solution in principle, because it is not going to be a common (let's say daily) occurrence that static resources like JavaScript are not up to date. So this is going to add a lot of extra back and forth between client and server for mostly no reason, aside from invalidating caches right now.

I read a bit on the topic and it seems a common solution to this kind of problem is using versioned resource names like thescript.1.0.0.js and setting Cache-Control: immutable. The resources name is then updated (e.g. thescript.1.0.1.js) when one wants clients to get the new version, leading to a cache miss.

That seems like a better fit for what we want to achieve, but I'm unsure if it is worth the effort of having to potentially change file names a lot in the future. I think it depends mostly on how abstracted the resources are handled in the Server code, i.e. how often their actual names show up there instead of using generalized functions like serveDirectory. Also it could be that fiddling with DirectoryConfig from Snap.Util.FileServe could partly or completely automate this, so we only need to edit a version tag once per change and leave the files alone otherwise.

@nimec01 what do you think about this? Is that reasonable in light of how the server interacts with served files?

[nimec01]

I'm not really satisfied with this solution in principle, because it is not going to be a common (let's say daily) occurrence that static resources like JavaScript are not up to date. So this is going to add a lot of extra back and forth between client and server for mostly no reason, aside from invalidating caches right now.

Yes. This should really just be the quick and dirty fix.

I read a bit on the topic and it seems a common solution to this kind of problem is using versioned resource names like thescript.1.0.0.js and setting Cache-Control: immutable. The resources name is then updated (e.g. thescript.1.0.1.js) when one wants clients to get the new version, leading to a cache miss.

That seems like a better fit for what we want to achieve, but I'm unsure if it is worth the effort of having to potentially change file names a lot in the future. I think it depends mostly on how abstracted the resources are handled in the Server code, i.e. how often their actual names show up there instead of using generalized functions like serveDirectory. Also it could be that fiddling with DirectoryConfig from Snap.Util.FileServe could partly or completely automate this, so we only need to edit a version tag once per change and leave the files alone otherwise.

The web client is really just basic HTML, CSS and JavaScript. Thus changing a filename would require us to also update all references to that file in the code. The way to go would be to use some kind of bundler that automatically does that for us. But I didn't want to try that yet.

[patritzenfeld]

I'll open an issue concerning what we discussed here, but it is more important to make sure students don't encounter problems next week (see Slack conversation).