Download builder URLs break after any single package gets a patch release

ernstki

Link to test case:

https://datatables.net/download/builder?dt/dt-2.3.2/b-3.2.3/b-html5-3.2.3/fh-4.0.2

Error messages shown:

curl -I https://datatables.net/download/builder?dt/dt-2.3.2/b-3.2.3/b-html5-3.2.3/fh-4.0.2

HTTP/2 200
date: Fri, 27 Jun 2025 14:42:46 GMT
content-type: text/html; charset=UTF-8
server: cloudflare
vary: Accept-Encoding
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
⋮

curl https://datatables.net/download/builder?dt/dt-2.3.2/b-3.2.3/b-html5-3.2.3/fh-4.0.2

Error: Only libraries of the current release version can be used by the. package builder. The library FixedHeader's current release version is 4.0.3. Please reload the download builder page to have it use the latest libraries.

Description of problem:

I'm not sure if this is a problem per se, or just mismatched expectations on my part… I get that what the download builder has to do, in terms of the many permutations of libraries with extensions, is pretty incredible as it is, and that I am essentially reverse-engineering a URL out of the download builder in a way that maintainers probably didn't envision.

But it seems like patch releases and minor releases should be retained for a while, so that the URL of a pre-built download can depended on to work for a while, e.g. in an automated deployment scenario, or in a CI/CD config.

What happens currently is that download URL stops working, but it doesn't return an 400 or a 404 Not Found either, so it's more of a challenge to catch that error (than just, say, inspecting a return code from curl).

Is there some better way of accomplishing what I'm trying to accomplish — stable downloads, without the need to install Node.js or use NPM?

Would it be possible to keep all minor versions around in the S3 bucket or wherever all these are stored, instead of removing them and breaking the URL when any package has a patch-level release?

allan

Hi,

Thanks for posting this. This is correct and expected for the download builder when creating a package to download - it supports only the latest versions. You could use the version feed if you wanted to automate it, or you can just download the JS and CSS files from the CDN, which do support any version combination and I'd probably recommend this approach instead.

Allan

ernstki

I had a feeling I was (badly) attempting to automate something that was truly only intended for one-off interactive use.

Seems silly now, but for some reason, it had not occurred to me to simply download the same files from the CDN. :facepalm:

Minor point, but would it still be possible to return a 400 or 404 Not Found in the case described above?

Regardless, thank you, sir. Have a good week.

ernstki

For future visitors, here's how to do what I was trying to do above, except using the CDN instead of the download builder. Assumes the Bash shell, due to the use of brace expansion.

# instead of https://datatables.net/download/builder?dt/dt-2.3.2/b-3.2.3/b-html5-3.2.3/fh-4.0.2/…
# -fSS = silent but still show errors; return non-zero for 4xx or 5xx errors
curl -fsS --remote-name-all https://cdn.datatables.net/v/dt/dt-2.3.2/b-3.2.3/b-html5-3.2.3/fh-4.0.2/datatables.min.{js,css}

allan

Good idea! I've made a change so that a request that results in an error (e.g. an old package version) for the download zip, will now return a 400 status code.

Allan