Jsdelivr: Allow accessing github gists

[ackvf]

Is your feature request related to a problem? Please describe.

I have a userscript file for Tampermonkey/Greasemonkey, but I can't link it with an error:

Mixed Content: The page at 'https://np....com/game/....' was loaded over HTTPS, but requested an insecure script 'http://np....net/qscript-nptriton.devel.monkey.js'. This request has been blocked; the content must be served over HTTPS.

SSL is expensive on my hosting so I uploaded the script to github gist which serves files over https, however, I then get another error, because github gist sets the MIME type to text/plain even for scripts for security reasons.
Loading such a script on a page gives:

Refused to execute script from 'https://gist.githubusercontent.com/...' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

Describe the solution you'd like
I would like to be able to use this^ solution that works for standard github repositories also for gists.

http://cdn.jsdelivr.net/gh/<username>/<repo>/path/to/file.js

The main difference and benefit of using gist is that gists can be secret while accessible for anyone with link, but repositories are either completely public or private.

These issues are about the same, but they are closed https://github.com/jsdelivr/jsdelivr/issues/18264 https://github.com/jsdelivr/jsdelivr/issues/18200#issuecomment-754969737

[SukkaW]

I don't know why you people asking for gist support.

You already see those closed issues, can't you just figure out why they are closed?

And if you really need a CDN for gist, why don't you guys build your own CDN?

[jimaek]

jsDelivr was built for production use. That means having a versioning system. Creating a Github repo and tagging your releases is not that hard but it allows us to offer a more stable service.

Supporting gists is simple but building the codebase to support gists in a reliable way is not so trivial. We have multiple levels of caching, we cache files permanently to make sure a deleted file won't break thousands of website, we do internal optimizations...

Lots of things come together to offer a reliable production service. Spending our limited dev resources on gists doesn't make sense for me for now, especially when using Github directly is just as simple.

If in the future we end up with a big full-time dev team then it's something I would consider doing.

Thanks all

[egfx]

Wow supporting gists in simple and you're not doing it? Just do it. This is super useful and there is a reason why people are asking for this and searching for it as well. For example, I prototype web apps. My build process is unique. It's comprised of mashed up scripts to do things fast. I don't want to waste time on other things such as deployment concepts or making github repos. And especially building CDN's.

[jimaek]

What happens if the Gist gets deleted? What if its edited? How do we track the updates? We will need a perm caching solution to make sure deleted gists dont break websites... There is lots of logic involved if we want to make this reliable.

I agree that just building a proxy for gist is simple, making it production ready and scalable is not.

Also our service wasn't built for dev testing and prototyping. We utilize multiple caching layers for optimal production performance which also means changes are not instant, that would also be a deal breaker for prototyping and quick tests.

[SukkaW]

Wow supporting gists in simple and you're not doing it? Just do it.

Then just build your own then. It is simple, as you said.

As I said before:

And if you really need a CDN for gist, why don't you guys build your own CDN?

[34r7h]

lame