Docs site is broken
adrianbj opened this issue · 18 comments
Hi @SidVal,
The 404 error was most likely caused by a temporary unpkg.com outage, not an issue with the URLs used. Unpkg.com URLs should not have trailing slashes.
Thanks for posting the issue so quickly though. Much appreciated. All seems to be resolved.
But...
The 404 error was most likely caused by a temporary unpkg.com outage
How did you know that?
It was an assumption based on the fact that I see no issue loading the following URL:
The above URL redirects to the following URL as expected:
All sites load fine on my end.
Adding a trailing slash, like this:
Results in a web page being displayed that lists the content of the NPM package. This is not what we want.
Perhaps the first URL is being blocked or the redirect isn’t working for some reason where you are located? Can you try loading either of the first two URLs (without the slash) and let me know if they resolve as expected?
Thanks for the feedback, @SidVal.
Turns out this is caused by an issue with unpkg.com: mjackson/unpkg#156
The short summary is that some of unpkg.com’s redirect features are broken, causing URLs like the ones listed on this lib to fail. Hopefully the issue gets resolved quickly and all goes back to normal without making any changes. If a fix isn’t in place in the next day or so, then I’ll have to update the links to link directly to files (which I'd prefer not to do).
Ugh. Frustrating. Thanks for the heads up, @SidVal. More to come...
That issue (mjackson/unpkg#156) has now been closed but I am not seeing any change here. Perhaps it's a caching issue somewhere?
Hi @adrianbj.
My understanding based on the mjackson/unpkg#156 thread is that the fix will not be immediate for everyone as a result of some CDNs cacheing the broken redirect. This is why some (like myself and others in the unpkg thread) have no issues while others continue to get 404 errors. Eventually these CDNs will update with the correct redirect URL and all will go back to normal.
Until then, you can work around the issue by linking directly to a specific version of the script file:
Or the latest version:
Note that using either of the above URLs is less than ideal because you're either 1) linking to a specific version of the script, so you want automatically get non-breaking updates (e.g. 1.1.1 to 1.1.2 or 1.2.0) or 2) you are always linking to the latest version of the script which means a new release with breaking changes could break your site (e.g. 1.1.1 to 2.0). This is why I prefer using the semver-based URL scheme link like https://unpkg.com/docsify-tabs@1 which will load the latest version of 1.x but not 2.x.
@SidVal + @adrianbj -- since you seem to be affected by the cached CDN issue, would you mind reporting back over the next day or two to confirm that the issue has been resolved? To be clear, we're looking for this URL:
To automatically redirect to this:
Thanks!
Well, did not a CDN issue if unpkg server had a bug reported (now fixed).
I agree with you to wait two days before closing this issue.
When I click on: https://unpkg.com/docsify-tabs@1
It's ok, and I get:
/*!
* docsify-tabs
* v1.1.1
* https://jhildenbiddle.github.io/docsify-tabs/
* (c) 2018 John Hildenbiddle
* MIT license
*/
!function()...
But, with this example: https://unpkg.com/docsify-copy-code@latest
I get: Cannot find "/index.js" in docsify-copy-code@2.0.2
Or, https://unpkg.com/docsify-copy-code@2
I get: Cannot find "/index.js" in docsify-copy-code@2.0.2
I tested with a Incognito Chrome ... 🤔
Thanks for the follow-up , @SidVal.
Looks like progress is being made... slowly.
There are still a few folks reporting issues in the mjackson/unpkg#156 thread, but that fact that the original docsify-tabs link (https://unpkg.com/docsify-tabs@1) is now working for @SidVal is a good sign.
@adrianbj -- how do things look on your end? Are you able to load the docsify-tabs site now?
@jhildenbiddle - it still doesn't work for me and I have tried multiple VPN connections to different locales with no luck.
That said, I can successfully load: https://unpkg.com/docsify-copy-code@latest and https://unpkg.com/docsify-copy-code@2 which @SidVal said failed.
Thanks for the quick reply, @adrianbj.
This is definitely frustrating. Apologies for the downtime. Hopefully this is all resolved in the next 24-48hrs. If not, I'll manually the URLs on the site to work around the issue.
If you guys wouldn't mind reporting back in the next day or two, I'd very much appreciate it. Unfortunately I don't have access to VPN nodes in Argentina or British Columbia so I can't test for failures in your areas.
Thanks!
Also, be sure to test either in private/incognito mode or specifically disable caching via dev tools when testing. DNS queries can be cached locally, so one broken response can persist if you’re just refreshing without specifically disabling caching.
Computers. So hard. 😉
Just a quick update - locally still everything is failing, but now on VPN connections to Europe, Asia, and North America (don't know where) it's mostly working, just https://unpkg.com/class-change
that is still failing.
Hopefully it will be up here soon also.
Looks like it's finally all working here :)
Although I am still seeing this with Google Analytics:
jhildenbiddle.github.io/:65 GET https://unpkg.com/docsify/lib/plugins/ga.min.js net::ERR_BLOCKED_BY_CLIENT
Thanks for the follow-up, @adrianbj.
The maintainer of unpkg.com has cleared the cache for the three packages I mentioned specifically (docsify, docsify-copy-code, and class-change) as well all redirect URLs on unpkg.com (1, 2). Hopefully this resolves the redirect issues for all packages on unpkg moving forward.
Moving forward, I have decided to change the CDN links listed in my packages from unpkg.com to jsdelivr.com as a result of these redirect issues. As much as I appreciate unpkg.com and the unique "automated CDN from NPM" offering it pioneered, jsDelivr offers similar automated CDN services for npm packages along with additional features like support for GitHub repos, package statistics, automatic bundling and minification, and subresource integrity checks.
The documentation for both docsify-themeable and docsify-tabs have been updated along with the CDN links used in each site's index.html
(here and here). You may want to consider doing the same with your own docisfy sites and packages, as leverage the @version
feature in your URLs to lock CDN resources to specific versions.
Thanks again for working through this, and apologies for any downtime the redirect issues may have caused.
@adrianbj --
Regarding the ERR_BLOCKED_BY_CLIENT
error, this is most likely caused by an adblocker blocking a request for the Google Analytics script. This won't affect your ability to use the site, but it does mean your visit will not be included in the site's analytics reports. Disabling your adblocker (which you can usually do on a per-site basis) should resolve the issue.