Aggressive image caching breaks image badges #224
Description
Seems like the way README images are cached by GitHub is too aggressive.
For instance its braking the Cocoapods' badges like the one from this (README)[https://github.com/CyberAgent/iOS-NBUKit/blob/master/README.md] by replacing the perfectly functional image URL:
http://cocoapod-badges.herokuapp.com/v/NBUKit/badge.png
(The image above may be also wrongly cached!)
Seems like using https instead of http works.
https://cocoapod-badges.herokuapp.com/v/NBUKit/badge.png Now https is also broken.
Activity
bkeepers commented on Jan 28, 2014
We have to proxy HTTP requests to avoid mixed content warnings, and therefore also cache the content to avoid excessive load. The HTTPS versions do not get proxied.
Update: The HTTPS versions also get proxied now. Assets must include Cache-Control: no-cache and ETag headers. If a badge is not updating, then it means they are not properly setting these headers. See my comment below for more info.
rivera-ernesto commented on Jan 29, 2014
Then maybe it should be stated in the documentation somewhere. Maybe https://github.com/fletcher/MultiMarkdown/blob/master/Documentation/Markdown%20Syntax.md?
Thanks for the explanation!
jmalloc commented on Jan 29, 2014
HTTPS images are cached now ... https://github.com/blog/1766-proxying-user-images I can certainly understand the need. Hopefully the cache times are kept low so that status badges aren't completely useless ;)
rivera-ernesto commented on Jan 30, 2014
Ouch
bkeepers commented on Feb 3, 2014
@josh Can you speak into the cache ttl and how it effects build status images?
josh commented on Feb 3, 2014
The CDN caching respects HTTP Cache-Control. Set it accordingly.
tomchentw commented on Feb 9, 2014
Hmm... badges are cached now, one can see the coverage on Github are outdated compared to NPM's:
https://github.com/tomchentw/ng-fire-alarm
https://npmjs.org/package/ng-fire-alarm
Any ideas?
Updated: 2014/02/18
The badge of coveralls.io still doesn't work.
#224 (comment)
jmalloc commented on Feb 10, 2014
FYI @ezzatron
tomchentw commented on Feb 16, 2014
It's annoying, I tryed to recreate my coverall.io project. After a success build, it still references to the wrong badge. WTF?
h12w commented on Feb 16, 2014
I also met the same issue of obsolete coveralls.io badge. The update may take several hours.
Also:
rvagg/nodei.co#9
tbranyen commented on Feb 17, 2014
Not sure why this is closed. It's still a huge problem. If a service wants to provide a badge, why not leave it up to them to provide the CDN?
As it stands the badges are fairly useless now on projects I maintain.
rivera-ernesto commented on Feb 17, 2014
Also a problem when updating screenshots or just any image.
bkeepers commented on Feb 17, 2014
This should not be a problem as long as the external service sets the proper headers. For example, here are the relevant headers in a response from Travis CI.
coveralls.io is setting Cache-Control. That should be enough (I'll look into why that's not). If anyone has connections at coveralls.io, you might want to suggest that they also Expires, and if they can support it, Last-Modified and Etag.
bkeepers commented on Feb 17, 2014
@tbranyen, @rivera-ernesto what services are you seeing issues with? Let me know and I'll look into why they're not working.
27 remaining items
Stasik0 commented on Jul 7, 2014
our coveralls coveralls.io badges are also cached and broken since yesterday https://github.com/acplt/open62541/blob/master/README.md
dbrgn commented on Jul 7, 2014
Same issue as @FabianFrank here. Internal build server. The badge should be visible internally, it does not matter whether it breaks from the outside or not. Please provide a way to turn off the caching.
bogdanRada commented on Jul 8, 2014
for me it works if i have the headers of the Cache-Control and the Expires .
you can check it here : https://github.com/bogdanRada/ruby-gem-downloads-badge/blob/master/README.md
But it only works if all links are using HTTP.
Using links with HTTPS doesn't work for some reason .
bogdanRada commented on Jul 8, 2014
actually for me works with HTTPS also, i just needed to change the urls , since they were already cached and it didn't saw the new headers i added. But after changing them it works
bkeepers commented on Jul 9, 2014
I'm looking into how we could accommodate assets that are behind a VPN. I think the ideal solution would be that the CDN would just do a redirect on assets that it can't access, but I don't know if that is feasible or what the ramifications are.
FabianFrank commented on Jul 9, 2014
@bkeepers I guess you mean that Github would do a redirect to the resource if it can't fetch it?
bkeepers commented on Jul 9, 2014
@FabianFrank yeah that's what I meant, corrected comment above.
bkeepers commented on Jul 9, 2014
Sorry, I looked into it and handling assets behind a VPN is not going to work right now. CDNs don't really support the idea of redirecting you to a private resource. Someday we might investigate giving repository owners the ability to disable image caching, but it doesn't make sense for us to work on right now.
If this affects you, I would encourage you to contact support@github.com so we can track it and have a sense of how many people this impacts.
bkeepers commented on Jul 9, 2014
We're pretty confident that the image caching works. If you're having issues with something like a CI badge, make sure the image has the Cache-Control: no-cache header, and either Expires, Last-Modified or Etag. See the Fastly documentation for more info.
If you're still having issues, contact support@github.com
feat(badge): set header
Add Cache-Control: no-cache to /badge.svg
Update README.rst
Added abaplint banner, minor readme fixes
remove github example from readme