Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub now caches SSL images in README on main repository badge #111

Closed
sqs opened this issue Jan 28, 2014 · 8 comments
Closed

GitHub now caches SSL images in README on main repository badge #111

sqs opened this issue Jan 28, 2014 · 8 comments

Comments

@sqs
Copy link

sqs commented Jan 28, 2014

GitHub apparently must have just recently started caching SSL images in READMEs on a repository's main page.

For example, go to https://github.com/bower/bower and check the image URLs for the Travis CI and Sourcegraph badges. They are cache URLs: https://github-camo.global.ssl.fastly.net/007fb2bce5....

But if you go to https://github.com/bower/bower/blob/master/README.md, the badge image URLs are the original URLs (https://secure.travis-ci.org/bower/bower.png?branch=master and https://sourcegraph.com/api/repos/github.com/bower/bower/counters/views-24h.png and).

The HTTP headers include a link to https://camo.githubapp.com/, which suggests that GitHub is camouflaging these HTTP requests. It's not just camouflaging, though; GitHub's CDN also appears to be caching the images in violation of (for a longer duration than allowed by) the origin server's cache headers.

I wanted to bring this up because it affects how dynamic the badges can be. Previously, I think we had all assumed that GitHub would not cache SSL images.

@seanlinsley
Copy link
Contributor

This was just announced on the Github blog: https://github.com/blog/1766-proxying-user-images

@nathany
Copy link
Contributor

nathany commented Jan 29, 2014

I guess that (intentionally) removes any possibility of doing analytics #93 with any accuracy.

This was referenced Jan 29, 2014
@fjcaetano
Copy link
Member

Does anyone know a workaround for this yet? How can badges/pypipins be working?

@sqs
Copy link
Author

sqs commented Jan 30, 2014

Badges are still refreshed frequently, just not (according to my experimentation) necessarily in accordance with the cache headers set by the origin host. So the download count might be slightly out of date.

@espadrine
Copy link
Member

Can you define the exact issue?

Some notes:

  • HTTP was already cached by GitHub
  • According to Zach Holman, sending the no-cache header (which we do) should prevent caching
  • The server has an internal cache of a minute, to avoid spamming the vendor's servers.

@sqs
Copy link
Author

sqs commented Jan 30, 2014

There's no immediate issue for this project, but I did want to raise it because it affects some potential directions that had been mentioned (like badge analytics).

The specific issue with caching headers I mentioned was that I wasn't seeing the badge image be re-requested from the origin server despite setting what I thought were the correct Cache-Control headers. I haven't had time to investigate that more, but I'll report back if I see any issues.

@chadwhitacre
Copy link
Contributor

Thanks for the heads-up, @sqs. :-)

@hobbyquaker
Copy link

I made a little tool to clear the camo cache, you can call that in your build process to keep your badges always up to date. https://github.com/hobbyquaker/camo-purge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants