Modify server.js to enable cache headers to be explicitly specified in tiddlywiki.info

[rubaboo]

Discussion here: https://groups.google.com/forum/#!topic/tiddlywiki/xWqZnXmYyhU

[Jermolene]

Thanks @nameanyone

[pmario]

Text from GG mentioned in the OP ... Seems to be still valid

My setup:

• Firefox on Windows desktop
• Node.js
• Content wikis “work” and “home”, each includes a “base” edition wiki which contains all my customizations.
• I don’t serve the base edition separately. When I need to modify any customizations, I just do it from “work” or “home”, and then restart the other one so it picks up the changes.

I was noticing that even after a restart of tiddlywiki and a page refresh in the browser, I would still see a previous version of a tiddler that I edited in the other wiki. A second page refresh would then bring up the updated version.

Here’s a tiddler I created to disable caching and it seems to have helped:

tags: $:/tags/RawMarkup
title: HTTPHeaders
type: text/vnd.tiddlywiki

<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="cache-control" content="no-store" />
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="expires" content="0" />

---

Jeremy's response ... which hasn't been implemented yet

Interesting, I've not encountered this before. It may be worth making a github ticket for a more flexible solution: to modify server.js to enable cache headers to be explicitly specified in tiddlywiki.info

[Jermolene]

Thanks @pmario @rubaboo

[joshuafontany]

@pmario @Jermolene I ran into an issue with browser caches at work, and realized it may explain some client/server weirdness that I have seen with tiddlywiki. The current advice around this is to NOT use meta tags in the head element, but to have the server set the cache-control headers directly (as Jeremy suggested).

Tiddlywiki delivers the initial "package" of tiddler data inside the HTML, with no cache-control header specified. So the default "not specified" caching takes over, which is browser controlled via heuristic algorithms (unpredictable). As soon as a change is synced back to the server, the HTML in the browser cache is a race-condition-waiting-to-happen. If the page is refreshed and the tiddlers are re-loaded from the OLD cached HTML.... and then synced. Oops, just wiped out a bunch of work, didn't we?

This may be important to clear up for the MWS work. I am getting back into working with TW servers, so may be able to get an idea of where to include this. Are we sill using tiddlywiki.info files to define MWS wikis? Where else can we specify these configs?

https://www.cloudflare.com/learning/cdn/glossary/what-is-cache-control/

cache-control: no-store
A response with a ‘no-store’ directive cannot be cached anywhere, ever. This means that every time a user requests this data, a request must be sent to the origin server for a fresh copy. This directive is typically reserved for resources that contain extremely sensitive data, such as bank account information.

cache-control: no-cache
This directive means that cached versions of the requested resource cannot be used without first checking to see if there is an updated version. This is typically done using an ETag.

An ETag is another HTTP header which contains a token unique to the version of the resource at the time it was requested. This token is changed on the origin server whenever the resource is updated.

When a user returns to a page with a ‘no-cache’ resource, the client will always have to connect to the origin server and compare the ETag on the cached resource with one on the server. If the ETags are identical, the cached resource will be provided to the user. If not, this means that the resource has been updated and the client will need to download a fresh version to provide to the user. This process ensures that the user is always getting the most up-to-date version of that resource without requiring unnecessary downloads.

[Jermolene]

Thanks @joshuafontany I've created a new issue with your comments here: #8138

[joshuafontany]

@Jermolene I have been doing some extensive testing with the use-browser-cache=yes command line argument.

This feature satisfies all the caching concerns I could think of:

• save all image tiddlers from tw5.com-server into /output/tiddlers/* -> copy to /files/tiddlers/*
• run regular server with use-browser-cache=yes flag
• make _canonical_uri exernal tiddlers for some of the images in /files/tiddlers/*
• make sure they are cached and used correctly when opening/closing those external tiddlers
• make sure that the polling to GET /recipes/default/tiddlers.json?filter=<filter> uses caching correctly

I saw a very large bandwidth reduction, and correct 304s returned to use already cached responses that match the current Etag.

I also confirmed that you are NOT using state.sendResponse() in the PUT /recipes/default/tiddlers/:title route (the only other place that uses Etags).

This caching behavior (and the no-store default) should be called out in other places than just the [[Using the external JavaScript template]] tiddler. I will open a PR for that, and I consider this issue resolved.

[pmario]

... I will open a PR for that, and I consider this issue resolved.

@Jermolene .. Can you close this issue form 2015?

[Jermolene]

Thanks @joshuafontany @pmario