CDN specific versions not available?
CDN specific versions not available?
phew01
Posts: 1Questions: 1Answers: 0
Hi,
Am using datatables via Backpack for Laravel. All of a sudden yesterday, all tables were broken / stopped working.
Upon investigation, it seems that cdn.datatables.net is not serving some older versions (cannot upgrade, am dependent on the Backpack kit).
This is specifically for
datatables 1.13.1
buttons 2.3.2 & 2.3.3
fixedheader 3.3.1
responsive 2.4.0
I have created a workaround (took the first higher available version and arranged with Backpack that I use local versions.
However, it seems odd those specific older versions are missing. There are even older versions still available.
Is this for a reason? If so, then I'll push Backpack to upgrade their versions used.
Thanks,
Piet
Answers
HI Piet,
I'm so sorry you are having these problems. For DataTables 1.13.1: https://cdn.datatables.net/1.13.1/js/jquery.dataTables.min.js appears to be loading okay for me. That particular version appears to be missing and index page, which is something I'll look at addressing, but that has always been the case. The JS and CSS are what matter and they should be loading. Try adding
?2025-07-30to the end and see if that helps - there might be an HTTP cache?The same appears to be the case with the others you list - e.g. I can load the Buttons JS but again it is missing its index page.
Regards,
Allan
We are having the same problem, though only to some of our customers. Some of them have no problem loading the files for this version, but others can not load it (also started yesterday). We have transferred the file locally and now it works for everyone.
exact versions used:
https://cdn.datatables.net/v/dt/jszip-2.5.0/dt-1.13.1/b-2.3.3/b-html5-2.3.3/sr-1.2.0/datatables.min.js
I've just deployed an update to address the missing index files, such as for DT 1.13.1. It doesn't make a functional difference I know, but it does fill that gap.
@tortor - Many thanks for the link. There is some HTTP caching somewhere in front of some of your customers which is causing the issue now. You could try adding a query parameter to the URL to "bust" the cache - e.g. like this. The link you provided appears to load for me no problem over two different networks, which is why I believe it is an HTTP cache issue.
Allan
I'm having the exact same issue as tortor in all my apps...
How can I fix this to reassure my customers ?
URL used :
https://datatables-cdn.com/v/bs5/jq-3.6.1/jszip-2.5.0/dt-1.13.1/b-2.3.3/b-colvis-2.3.3/b-html5-2.3.3/b-print-2.3.3/r-2.4.0/sp-2.1.1/sl-1.6.1/datatables.min.js
Regards
Won't work and will never have worked as I don't have jQuery 3.6.1 available on the CDN! Using 3.6.0 or 3.7.0 will work though.
Change the jQuery version in your URL and it will start working again. That is not something that was caused by yesterday's outage I'm afraid, as I say, jQuery 3.6.1 isn't in the CDN's cache at all.
Allan
Thanks @allan.
I ran a lot of tests yesterday (including changing the jQuery version). There's a small detail I forgot to change back to its default value.
Test in my first application: OK.
Regards
I believe it is a CDN problem and not a cache problem - the files generate a 404 error, see image
@tortor Looks like one of the URLs you are trying to use is this:
https://cdn.datatables.net/v/dt/jszip-2.5.0/dt-1.13.1/b-2.3.3/b-html5-2.3.3/sr-1.2.0/datatables.min.js
That URL works for me. Have you tried the above workarounds Allan suggested to break the cache?
Kevin
It will either be HTTP cache, or I suspect in your case DNS cache. If you set your internet connection's DNS servers to 8.8.8.8 and 8.8.4.4 (Google's public DNS servers) those files should load no problem.
You could also try flushing your DNS cache, although that might be your computer, your router or ISP's router.
Allan
Actually for me it works fine which is why it is hard to debug. But we have many customers who are showing 400even after we added parameters to the url. It looks like a certain group of our customers (which we cant identify easily). are not able to reach the cdn
Perhaps flushing the datatables cdn cache?
I've already done that.
It is showing a 400 error rather than a 404 for them? I very much suspect they'll need to reboot their router, or otherwise clear its DNS cache. If they are technically minded, ask them to
dig cdn.datatables.net. If there is a single IPv4 address in the response, that's stale DNS. There should be three IP addresses pointing at CloudFlare servers.Unfortunately there is very little I can do at this point since I don't have access to whatever is caching their DNS. Have you tried replacing
cdn.datatables.netwithdatatables-cdn.com(the path stays the same). That should solve the DNS cache issue - unless you've got a Cisco router which is configured to block new domains...Allan
My mistake - 404. We are not talking about 1 or 2 users, we are talking about over 120 users we know so far. We cant just tell everyone to reboot their routers. We will probably have to update our code to 1.2.1, only problem is it is in lots of pages.
How's it looking this morning. The only alternative I can offer you is to do the domain name swap I mentioned above. The paths are identical, you just need to replace
cdn.datatables.netwithdatatables-cdn.com- there won't be any DNS TTL issues there. It is maddening that some routers are still using the wrong resolver, but I'm afraid there isn't anything I can do about that other than to suggest the alternative.Allan