search

badges / shields

Concise, consistent, and legible badges in SVG and raster format
https://shields.io
Creative Commons Zero v1.0 Universal
23.36k stars 5.49k forks source link

'Waiting for img.shields.io" #445

Closed weitjong closed 7 years ago

weitjong commented 9 years ago

After changing our project website to use shields.io, it frequently has long wait to render the badges. When we have problem in the badge rendering on our website, the http://shields.io/ also has the similar problem. So, I guess the problem is not on our side.

Is there any way to improve this? I am considering to switch back to use the original badges from their respective service providers. It is better to get a reliable low resolution version than an unreliable high resolution badge.

patrikhuber commented 8 years ago

My badges still don't load (see my post & repo link above), do you have any idea what I could try?

pkoretic commented 8 years ago

@patrikhuber @espadrine

I have the same problem, seems that github link for license badge inside readme doesn't work for some time now replacing it with direct link works

[![License](http://img.shields.io/:license-mit-blue.svg)](http...)

patrikhuber commented 8 years ago

I just checked and was very surprised to see the license and version badges load a few minutes ago. I refreshed a few times and it was working each time.

Now, 3 minutes or so later, the release badge is back to not loading.

espadrine commented 8 years ago

@patrikhuber That's probably GitHub's rate limit on one server kicking in. I suggest using https://img.shields.io/badge/license-mit-blue.svg?style=flat-square instead. That will essentially instantaneously load.

algorys commented 8 years ago

Hello,

I've the same issue with my badges.

Travis badge working well, other (Github Badge : License and Releases) sometimes appears, sometimes not.

https://github.com/algorys/agshmne/

@espadrine I've tried your solution. That's working great but maybe too complicated to maintain for large project

patrikhuber commented 8 years ago

@espadrine Thanks. Is there a workaround/solution for the release version badges?

Are all shields users experiencing these problems, and if not, why only a handful of us? Why does this rate limit not kick in for others?

algorys commented 8 years ago

@patrikhuber you can make the same with your release but you have to change manually for each versions / tags :

[![GitHub release](https://img.shields.io/badge/release-v0.0.3-blue.svg)](https://github.com/algorys/agshmne/releases/latest)

But as I said before, if you release often it'll be hard to maintain.

espadrine commented 8 years ago

@patrikhuber I'm exchanging with GitHub to figure out a solution. The main issue is here: https://github.com/badges/shields/issues/529. It does affect everyone, although we do have two servers, so two IPs, presumably treated separately.

patrikhuber commented 8 years ago

@algorys I know, but that's not really a great option unfortunately.

@espadrine Cool, that's great to hear! Awesome. And thanks to the link to #529. It just seems a bit disappointing that the conversation hasn't advanced since Sept 2015. Anyway, glad to see I'm not the only one having this issue, and I hope there will be a solution soon.

marcelstoer commented 7 years ago

I've just gone through the comments in this issue and those in its sibling #529. As a result I also contributed tokens using https://img.shields.io/github-auth.

What I don't understand is why GitHub would switch img src URLs from https://img.shields.io/ with those from https://camo.githubusercontent.com/ at all. After all, it'd be the browser making those requests and thus hit shields.io. Why would GitHub want to redirect (and cache) those? To me that makes particularly little sense for "static" badges (i.e. those that don't need to access GitHub resources to render) such as license or Twitter.

espadrine commented 7 years ago

@marcelstoer Originally, the point was to avoid mixed-content warnings which browsers raise when a HTTPS page has resources (eg. images) fetching data over insecure HTTP. You can read more on the subject on their README.

marcelstoer commented 7 years ago

Ahh, right... "mixed-content warnings", forgot about those - except that shields.io can be accessed over HTTPS as well.

espadrine commented 7 years ago

@marcelstoer Camo is now also used to set CSP information, which they rely on to avoid a class of vulnerabilities, things that are part of XSS or CSRF.

marcelstoer commented 7 years ago

Would self-hosting be a sensible alternative to all of us loading from https://img.shields.io?

pkoretic commented 7 years ago

@marcelstoer I've put my static badges to separate branch and linked that over rawgit service after too much trouble with img.shields.io, it's just not available most of the time I can confirm it works without issues, example: https://github.com/qaap/recurse

marcelstoer commented 7 years ago

@pkoretic I had already planned to do that for static badges as well. The majority of badges are dynamic, though (i.e. the make some API calls).

pkoretic commented 7 years ago

@marcelstoer yeah, I ignored them for now, probably the best is to add reverse caching proxy in front of them for your usage

marcelstoer commented 7 years ago

I believe there's a misunderstanding, either on your side or on mine 😉 What I meant was to host this project myself at let's say https://shields.mydomain.io. Then in my READMEs I'd use that domain. GitHub would still route them through camo but those requests wouldn't count against the https://img.shields.io rate limit.

pkoretic commented 7 years ago

@marcelstoer I understand, but it seems to much work for just badges it would be better if we could give more servers into the pool, since I too have spare dedicated servers which could take on that load

Thats why I recommended reverse caching proxy (using nginx for example)

That way you can still use your domain https://shields.mydomain.io which is proxy to https://img.shields.io so when https://img.shields.io is not available you will still get cached results instead of hanging

espadrine commented 7 years ago

The load has increased quite a bit lately: it averages 170 req/s at peak time. I'll add a server to the pool (I currently rely on two servers).

GitHub rate limits are not the issue anymore.

tankerkiller125 commented 7 years ago

@espadrine There is a module for Nginx that allows the load balancing feature to be controlled by a rest interface. And you could do an HTTP check on the servers like every 20s or so. This would allow people with additional servers to help out with handling the load with the minimal configuration for you to handle. Of course, this would need some authentication so that people can add and remove servers securely.

paulmelnikow commented 7 years ago

@espadrine Is there any action to take here?

espadrine commented 7 years ago

@paulmelnikow I believe the performance of the servers is more suitable nowadays.