GitHub README.md 이미지가 갱신/업데이트 안 되는 경우 해결법
GitHub Readme에 Dynamic Image를 넣을 때 발생한 문제 해결을 위한 글이다.
* 원래 링크는 내가 README.md 파일에 넣어준 링크를 의미하고 노랑색으로 하이라이팅했다.
* 호스팅된 링크/Camo링크는 내가 넣은 원래 링크의 이미지를 GitHub가 Camo로 호스팅한 링크를 의미하고 주황색으로 하이라이팅했다.
GitHub README.md에 내가 넣은 링크의 이미지가 바뀌면 호스팅된 README의 이미지도 자동으로 원래 링크에 이미지를 요청해서 업데이트가 될 것이라 생각했다. 그런데 원래 링크의 이미지가 변했음에도 레포지터리의 README에 있는 이미지가 옛날 이미지 그대로 남아있었다.
나의 경우 누나가 README에 백준 알고리즘 랭크, 푼 문제수, 실패한 문제 수를 나타내는 Badge(shield.io)를 넣고 싶어 했다. 서버에서 크롤링한 데이터를 기반으로 shield.io의 Static Badge 만들어주는 서버 링크를 변경하면서 Redirect 해주도록 만들었다. 그렇게 구현해서 이미지 링크를 README에 넣고 올렸는데 우리 서버에서 바꿔주는 이미지가 GitHub README에서 표시되는 이미지로 제대로 업데이트가 되지 않았다.
문제가 뭐였냐면 Camo와 Cache설정 때문이였다. GitHub는 이미지를 호스팅하기 위해서 위해서 오픈 소스 프로젝트인 Camo를 사용한다. 그래서 GitHub README.md 파일에 작성한 원래 링크는 쓰이지 않고 Camo를 통해서 생성된 URI를 쓴다. Camo는 익명의 URI Proxy를 생성해주기 때문에 GitHub REAME.md에 넣어준 나의 모든 이미지 링크는 모두 https://camo.githubusercontent.com/로 시작되는 링크로 바뀌어서 실제로 (Hosting해서) 사용된다.
Camo란?
https://github.com/atmos/camo README.md에 적힌 Camo의 설명
Camo is all about making insecure assets look secure. This is an SSL image proxy to prevent mixed content warnings on secure pages served from GitHub.
Camo가 뭔지 찾아보니 혼합 컨텐츠 경고(웹페이지가 HTTPS 연결을 통해 로드될 때 있는 일부 HTTP로 로드되는 Asset으로 인해 발생하는 경고)를 해결하기 위해서 SSL Image Proxy를 제공해주는 것이었다.
README의 링크가 어떻게 바뀌는지 보여주겠다.
README.md에 넣은 원래 이미지 링크이다. (우리가 만든 서버의 링크이다. 이 링크는 백준 사이트 크롤링 후 그 데이터를 기반으로 shield.io의 특정 링크로 Redirect 한다.)
![랭킹](https://algo-badge.herokuapp.com/badge/unodostre/rank)
실제 호스팅 된 README에서 클릭해서 들어간 이미지의 변환된 Camo링크이다. (GitHub가 내 이미지를 호스팅해서 쓰는 링크이다.)
https://camo.githubusercontent.com/bc0800f0523ed49ff870b7091eec80192d02a7e8/68747470733a2f2f616c676f2d62616467652e6865726f6b756170702e636f6d2f62616467652f756e6f646f737472652f72616e6b
요약하자면, 우리가 README.md에서 원래 달아준 링크인
https://algo-badge.herokuapp.com/badge/unodostre/rank로 들어가면 이미지가 바뀌어 있지만
실제로 GitHub가 호스팅해주는 Camo링크인 https://camo.githubusercontent.com/bc0800f0523ed49ff870b7091eec80192d02a7e8/68747470733a2f2f616c676f2d62616467652e6865726f6b756170702e636f6d2f62616467652f756e6f646f737472652f72616e6b로 들어가면 이미지가 갱신이 안 되어 있는 상황이다.
원래 링크의 이미지는 바뀌었는데
왜 Camo링크의 이미지는 갱신이 안 될까?
Cache 설정 때문이다.
내 서버는 Shield.io에서 제공해주는 Static Badge 부분으로 Redirect하는 방식으로 구현했다. Static Badge 부분은 정적 에셋용으로 설정된 캐시 정책이 반환되도록 되어있었다. (정적 Asset들은 보통 아주 오랫동안 캐시를 만료시키지 않도록 설정한다.) GitHub는 반환 받은 캐시 설정으로 Camo로 이미지를 호스팅을 했을 것이다. 그래서 GitHub Camo가 아주 오랫동안 캐시 된 이미지를 만료시키지 않았고 따라서 원래 서버로 재요청도 안 하게 된 것이다. 그랬기 때문에 호스팅된 README를 보면 (Camo링크를 통해 이미지를 불러오는데 거기선 아직 만료되지 않았다고 판단한 캐시된 이미지를 들고와서) 계속 옛날 이미지가 나왔던 것이다.
내 이미지의 캐시 정책 설정을 확인하려면 서버가 반환하는 cache-control Header의 값을 확인하면 된다.
나는 cURL을 사용해서 알아봤다. (curl의 -I는 응답된 헤더를 출력해주는 옵션이다)
curl -I <링크>
max-age(이미지가 최신 상태라고 판단할 최대 시간)가 86400초(=24시간)로 반환됐다. 24시간이 지나야 만료가 되도록 설정되어 있었던 것이다. cache-control이 안 설정되어 있어도 문제가 생긴다고 한다.
이제 문제가 뭐였는지는 파악했다. 그럼 해결을 해보자.
해결법
서버에서 반환하고 있는 캐시 정책을 올바르게 설정해주거나 캐시를 없애주면 된다.
1. 내가 이미지를 호스팅하고 있었는 경우 ( = 반환해주는 헤더를 수정할 수 있을 때)
반환해주는 cache-control 헤더를 올바르게 수정해주면 된다. (없다면 추가)
cache-control: no-cache
no-cache는 캐시된 것을 사용하기 보여주기 이전에, 재검증을 위한 요청을 원 서버로 보내도록 강제한다. 그래서 이렇게 하면 GitHub README에서 이미지가 업데이트가 안 되는 문제가 해결이 된다.
위의 방법이 GitHub Camo Troubleshooting 문서에서 적힌 방법인데 구글링 해보니 말고도 캐시 설정을 잘해주면 해결이 되는 것 같다. 예를 들어서, ETag, Expires, ...
2. 내가 이미지를 호스팅하지 않아서 헤더를 수정할 수 없는 경우
내가 이 경우에 해당됐다. 나는 다른 사람이 호스팅하는 shield.io를 사용하고 있어서 반환하는 헤더를 바꿀 수 없었다.
이 경우는 Camo의 캐시를 없애달라고 요청해야 한다.
캐시를 없애는 명령어이다! (curl의 -X는 사용할 메서드를 선택하는 옵션이다. 아래에서는 PURGE 메서드를 선택했다.)
curl -X PURGE <camo링크>
GitHub 문서에서는 캐시를 숙청(PURGE)하면 모든 사용자가 이미지를 재요청하게 돼서 최후 방법으로 쓰라고 하며 자주 사용하지 말 것을 권장한다. 이걸 그냥 사용해야겠따!!
주기적으로 또는 Redirect하기 전에 저 명령어를 한 번씩 때려주면 이미지가 잘 동기화될 것이다.
저 명령어로 Camo의 캐시를 없애고 내 컴퓨터의 Local 캐시도 없애고 Camo링크로 들어가니 내 서버에 요청을 다시하고 최신 이미지를 받아오는 것을 확인했다. 그리고 나서 GitHub 레포지터리에 들어가서 호스팅된 README에 들어가 보니 이미지가 최신 이미지로 잘 동기화가 되어있는 것을 확인할 수 있었다.
뭔가 찝찝하지만 ^^ 문제 해결 ㅋㅋ.
출처 및 참고한 문서
- https://github.com/github/markup/issues/224 이 GitHub Issue를 계속 읽어 내려가면서 해결해갔다.
- https://help.github.com/en/github/authenticating-to-github/about-anonymized-image-urls#troubleshooting-issues-with-camo 여기서 제시한 방법대로 하니 나는 다 해결이 됐다. 위에 Issue를 보면 이 문서대로 해도 안 되는 경우도 있다고 한다. Https로 하면 안 돼서 Http로 하니 해결이 된 경우도 있다 한다.
- https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control cache-control Header 내용을 참고했다.
-
Icons made by Freepik from www.flaticon.com
댓글
이 글 공유하기
다른 글
-
Git의 파일 상태 구분법
Git의 파일 상태 구분법
2020.04.09 -
Git Internals 정리 :: Git은 어떻게 동작할까?
Git Internals 정리 :: Git은 어떻게 동작할까?
2020.03.16 -
.gitignore가 동작 안할 때 상황별로 해결하기
.gitignore가 동작 안할 때 상황별로 해결하기
2020.02.29 -
Git/GitHub Commit 수정하기 :: Author / Contributor 수정하기
Git/GitHub Commit 수정하기 :: Author / Contributor 수정하기
2019.10.14