Automate Cloudflare Cache Flushing upon Release about sabnzbd.github.io

[shypike]

I only just updated latest.txt on sabnzbd.github.io. Is that the reason?

[jeffgeorge]

Nah, that's not the issue. The download buttons on the new site are based upon an asynchronous call to https://resources.sabnzbd.org/releases/json to provide URLs and version numbers and stuff.

I wouldn't be surprised if there's some extra layer of caching in place here -- possibly browser-level cache -- that makes browsers keep showing the old result even though the json is updated.

Thoughts, @Safihre?

[Safihre]

Yes, I did not turn on the cache-busting option (which would make jQuery automatically add a random number to the URL) in the call to $.getJSON because it adds a loading delay every time you go back to the main page within 1 visit.
So because of the expires header, browsers will cache the JSON for 24 hours without doing even a request if there's new version:

Maybe set the all those timeouts to 1 or 2 hours? You should also have control over the expires header it sends?

@shypike Maybe from now on, latest.txt can refer to https://sabnzbd.org/downloads?
Showing the right version for the visitor automatically and it also has the list of other platforms.
It looks a lot more user-friendly than the GitHub-downloads page.

(if the stable-release is newer than the testing-version, the testing version won't be shown, for clarity)

[shypike]

@Safihre If latest.txt points to https://sabnzbd.org/downloads, won't it be hindered by the caching we're discussing here? I'm quite sure that github's own download section isn't.

[Safihre]

True, but with the proposed changes that would be reduced to maximum 2 hours delay.
Since you usually update latest.txt a few hours after releasing, or the next day, that shouldn't be a problem since by then the cache has been long updated.

[jeffgeorge]

Ok, so I've just cut the minimum TTL on the json to 1 hour. Given this, when we release 1.1 if we do nothing, the download page should automatically update itself within 1 hour, because the CF cache and the $.getJSON() cache will both invalidate. Is that cool with everybody?

[Safihre]

The releases JSON is really slow, it takes 1.5-2 seconds to load.. Loading the GitHub-API takes only 400ms.

This inclines me to just use the GitHub API and parse it on the client side. This will also remove any caching issues, new downloads will be available right away.

[Safihre]

Switched to GitHub API now, much faster. I also used sessionStorage to save the data during the session, because the GitHub API doesn't use caching so if you would go from the homepage to the downloads-page it would make 2 requests. Now it only makes 1 for the whole session (so until you close the browser).

Will add a fail-method so in case the GitHub API fails or has a timeout the buttons will link to https://github.com/sabnzbd/sabnzbd/releases/

[shypike]

@Safihre Modified latest.txt

[Safihre]

@shypike the link did not work, /downloads/ is not the same as /downloads (so without the /) or /downloads.html in GitHub pages. I edited it :)