Closed weitjong closed 7 years ago
My badges still don't load (see my post & repo link above), do you have any idea what I could try?
@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...)
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.
@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.
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
@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?
@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.
@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.
@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.
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.
@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.
Ahh, right... "mixed-content warnings", forgot about those - except that shields.io can be accessed over HTTPS as well.
@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.
Would self-hosting be a sensible alternative to all of us loading from https://img.shields.io?
@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
@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).
@marcelstoer yeah, I ignored them for now, probably the best is to add reverse caching proxy in front of them for your usage
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.
@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
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.
@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.
@espadrine Is there any action to take here?
@paulmelnikow I believe the performance of the servers is more suitable nowadays.
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.