There is no lifetime applied in this case. In this case, we first check for the information on disk, and then fallback to a web request if it's missing. When fetching file lists, we assume that released libraries are static. Note that there is now a 1-day cache lifetime applied to the initial request, which should cut down on repetitive traffic. These operations will initially attempt a web request, and if it fails, fall back to the cached contents on disk (if any). When fetching versions (or catalog), we want to have live data if possible, as new versions (or packages) can be released.
#JQUERY CDN UNPKG FULL#
For Cdnjs, because they offer a full catalog, it also affects that. This affects the scenarios where we need to fetch the latest library versions or the file lists for a given library. I don't think it can solve the problem that cdnjs cannot connect This code retries up to 10 times, you can copy / paste one of the middle tags to add more retry attempts. I haven't used this a ton but I've observed it over a serious of a few weeks.
The more files there are, the more chance something 404's and it can be different every time which is making it impossible to restore some packages via this mechanism. Something- fails and then the whole thing fails. This is the behavior seen when trying to restore packages with a fair amount of files. I opened up the Chrome utilities and reloaded every few seconds and about 20% of the requests returned a 200 with the file, the rest 404'd with the same URL. However, if I navigate to that URL manually and it worked. I'm starting to think it's a CDN problem all together.
For instance, try to add the monaco-editor and it will consistently returns 404 for half of the files. Some packages you select will come down, but others fail consistently. You add your package in via cdnjs (because unpkg almost never works, in fact I've never personally got it it to work).
0 kommentar(er)
