Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Earlier Reverse Order Later
Caching[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Thu, Feb 13, 2020 03:17 PM UTC:

If caching on the site were broken, there would be no caching, and all changes would appear immediately. Your issue is that caching is working even when you don't want it to.


Ben Reiniger wrote on Thu, Feb 13, 2020 03:25 PM UTC:

...and the overzealous use of caching seems to be the browser, not our site.  I don't know what changed, or if there's an easy thing for us to do to override that browser behavior.  (On some pages we've been appending dummy unique ids as part of the query in URLs, which fixes the caching but is not ideal.)


H. G. Muller wrote on Thu, Feb 13, 2020 03:34 PM UTC:

As far as I am concerned, something is broken when doesn't fully work as it should. But this doesn't seem worth quibbling about, as long as we agree there is an issue.

It is unfortunate enough that the list of comments to the Betza Notation article gets cluttered with messages like this not directly related to the topic, and losing all relevance in a short time.

@Ben:

How do you know it is the browser? It doesn't look like it is the browser to me. In FireFox, when I press Shift during reload, it will always bypass the cache for the files the main document links to (like images or JavaScript code). And the main page will never be cached. But that does not happen here: I access chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js directly (so that the browser should never have cached it), and it still shows the old content. When I load the directory it is in, it gives the file with today's download date, so the correct file must be on the server.

When I append the requested betza.js link with a dummy CGI argument "t=19", to be sure no one can cache, I do see the altered content. But if I then omit it again, it reverts to the old content.

This happens on two browsers (FireFox and Chrome). After I use the Chrome menu to delete all cached files, I still get the old contents. I don't think it are the browsers.

I guess adding a dummy CGI argument that contains a dynamically requested time to the link in the page that refers to betza.js should fix it. But it is crazy that such a work-around would be needed.

[Edit] I added the dummy "?t=19" suffix to the link to betza.js in the Betza Sandbox comment, so that this at least uses the updated version. But it is not really a feasible solution to do that in every page that refers to the file. And when I update again the "?t=19" would be the cached version, and all the suffixes would have to be updated to a value never used before...


🕸Fergus Duniho wrote on Thu, Feb 13, 2020 04:54 PM UTC:

There are two levels of caching. One is browser caching, and the other is caching at the DNS/CDN level. The latter is handled by Cloudflare, and it reduces the server load quite a lot, which keeps this site quicker and more stable. I am able to control caching through page rules, but my free Cloudflare account gives me only three page rules. I have two rules right now. One disables caching for pages with a .php extension, and the other enables caching for the drawdiagram.php script, which is used for graphics. I can purge the cache for individual pages as needed, but I need to be asked to do that for a particular page. Complaining about caching in general will not help.


H. G. Muller wrote on Thu, Feb 13, 2020 05:16 PM UTC:

Such a setup breaks the possibility to change any of the articles and their associated uploaded files, as these are not PHP scripts. It makes you entirely dependent on manual intervention, because any update will with certainty be screened from all remote clients. If you want that, notification of the site admin or an editor that such intervention is needed should be automatic; having to post requests through the comments channel clutters the comments with garbage, as is now happening to this article.

Can the submission / upload script not automatically notify an empowered person that action is required, through e-mail or some specific requesting mechanism? It would of course be even better if these scripts would invoke a program that would purge the cached version in Cloudfare automatically.


🕸Fergus Duniho wrote on Thu, Feb 13, 2020 06:07 PM UTC:

I cannot control Cloudflare through scripts on this site. I have one page rule left. I could use it to disable caching on your script or on the directory it is in.


H. G. Muller wrote on Thu, Feb 13, 2020 06:35 PM UTC:

Well, if there are no other contenders for that rule, then it would certainly help me. Or perhaps exempt .js files in general: browsers would typically cache those themselves, so they won't request them even from Cloudfare unless the user would explicitly bypass or flush his browser cache.

But why are you so certain that you cannot control Cloudfare through a script on chessvariants.com? I guess you flush files from the Cloudfare cache (or perhaps the entire cache) through a TCP/IP connection. So why not have the submission script open a TCP/IP connection to it, and send the required commands over it? Or do you have to solve some "I am not a robot" puzzle there?


🕸Fergus Duniho wrote on Thu, Feb 13, 2020 08:15 PM UTC:

I set the rule to bypass the cache for https://www.chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js. There might be a way to purge the cache with a script, but I have not studied the Cloudflare API well enough to know how to proceed with that, and I don't know anything about using Curl. I normally just log in to Cloudflare's website and do it manually from there. I have also just increased the caching time from 4 hours to 3 days, so that HTML pages will stay up when the server goes down.


8 comments displayed

Earlier Reverse Order Later

Permalink to the exact comments currently displayed.