为什么有的同学提交的badge没有点亮？

[bigbeats]

大家可以随时去这个地址跟踪所有项目的进度：https://github.com/kaiyuanshe/Open-source-training-camp/blob/master/Projects.md

[bigbeats]

有同学配置了相关文件，但进入标题地址后发现badge没有点亮，这只是因为赵学长那里暂时还没有更新文件版本，更新周期大概是一天。

大家的issue可以多在这里发，装作互相不认识的网友，hhh！！！

[Jericaran]

明白啦，谢谢庞哥！庞哥机智啊！

[bigbeats]

以下内容摘自kaiyuanshe/Open-source-training-camp#10
首先说明一下，添加文件后 badge 若无法刷新，不要着急，24 小时内 badge 一定可以恢复正常。下面我解释一下这个原因。

GitHub 对在自己的网站上渲染的静态图片资源有一个缓存平台的，这也就是为什么我们在 GitHub 网站上看到的图片地址都是 https://camo.githubusercontent.com/***，而非文档中设置的 URL（一个是帮忙做资源缓存，另外对于类似 svg 中包含跨域请求的动态代码，则会进行清除，防止在 GitHub 网站上渲染时出现安全隐患）。而这里就涉及到了 HTTP 的缓存策略问题，在 HTTP 响应中，如果本地已经有该资源的情况下，在发起请求时会在 header 中带上 If-Modified-Since，即浏览器上一次的资源缓存时间戳。此时服务端会通过服务器的缓存策略来决定返回值，如果服务端有缓存策略，且自浏览器上次请求以来未有修改，则会返回状态码 304，表示 Not Modified，此时浏览器直接使用本地缓存显示资源即可，这样可以大幅降低网络静态资源导致的网络传输。

回到我们的机器人中，我们的机器人是这样的方式：file-checker/github/owner/repo?path=. 事实上会实时从 GitHub 获取文件状态，判断状态后 302 重定向到 https://img.shields.io/ 网站，只是根据文件状态不同，重定向的 URL 会不一样，但对于 shields 网站而言，确定的 URL 一定意味着确定的资源，所以其在返回的 header 中会带上一个 Cache-Control: max-age=86400，这表明发起方在 24 小时可以使用缓存资源而无需再次请求服务端资源。故 GitHub 认为只要 URL 不变，则该资源在 24 小时内无需重新请求。所以在浏览器向 camo.githubusercontent.com 请求资源时直接得到了 304 响应。

由于目前机器人 302 重定向的实现方式，使得文件缓存策略是由 GitHub 和 shields 网站通信决定了，机器人后端无法干预，所以目前的解决方式如下：

机器人不再使用 302 重定向，而是自己实现基于 svg 文件格式的 badge 服务，则可以通过在响应 header 中添加 Cache-Control: no-cache 来通知 GitHub 不要在自己的 camo 服务中进行资源缓存，每次都从后端获取即可。

这个目前可能没有时间来改，大家修改后可以稍安勿躁，最多 24 小时内一定可以刷新状态。

PS：如果文件中不包含任何内容，则后端会直接判断为 missing 状态。