Some resource downloads return CloudFlare anti-DDOS challenge pages.

[PhonicUK]

For example:

http://api.spiget.org/v2/resources/9089/download

This should be a .zip file as per the resource data, but instead hitting that URL returns a cloudflare anti-ddos challenge page.

[wouterdedroog]

Yup, and it isn't an issue that can be resolved by InventiveTalent as far as I know. She recommended me to host it myself.

[17:00] inventivetalent: well honestly, in terms of downloads I do recommend hosting stuff yourself - Spigot's cloudflare protection just makes the whole thing unreliable

[InventivetalentDev]

As MrWouter quoted, if you want to reliably download your resources your best option is accessing your own server to do so.
But I will add an additional check to the stuff that downloads resources to keep it from storing cloudflare pages, so you won't get any more corrupted .jar/.zip files.

[PhonicUK]

Is it worth perhaps reaching out to the Spigot guys to see if they can give SpiGet direct access as an IP whitelist?

[InventivetalentDev]

Is it worth perhaps reaching out to the Spigot guys to see if they can give SpiGet direct access as an IP whitelist?

Did that ages ago when I initially made spiget. Not happening.

[PhonicUK]

Darn, well making sure that things that aren't valid zips aren't saved should go a long way towards improving it :)

[PhonicUK]

I've been doing a little research and it may be possible to 'pass' the Cloudflare verification by using a headless browser. I've seen some approaches that actually just scrape and execute the javascript that it runs directly. But this does seen a really 'nasty' way to solve this particular problem.

[InventivetalentDev]

The current way the SpigetClient accesses has proven to be stable enough to not need a different solution.

[PhonicUK]

It may be worth combing through the existing plugin stores and removing/redownloading any that are either empty 0-length files or are HTML documents.