5 ms·
True, but I'm not worried about the extra bytes of an HTTP header. It's actually really useful when coupled with Rails+Unicorn w/ downtimeless deploy. Every on
by andrewvc 16y ago
True, but I'm not worried about the extra bytes of an HTTP header.
It's actually really useful when coupled with Rails+Unicorn w/ downtimeless deploy. Every once in a while unicorn will run a deploy but stop picking up code changes, and this is a good way to verify that your deploy didn't go all the way through.
Additionally, it integrates with shell scripts easier than most other solutions. Lastly, if you really want you don't need to make it an HTTP header, you can just make a special /git_sha page that renders it out if you're really worried.
Additionally, GIT_SHAs are good for cache busting in some situations (though totally inappropriate for others).
- marcc 16y agoThat's a really good point. Doing this will invalidate browser cache on most sites whenever you do a deployment. If you are the type that does production deployments throughout the day, then this could slow down the user experience. However, maybe you want an easy-to-use javascript cache reset tool for every deployment.
- deleted 16y ago[deleted]
- andrewvc 16y agoI'm fairly certain X-Whatever doesn't invalidate browser caches. I mostly meant it for things that need to invalidate on every release, since you can use the string to pass in to memcache as a query string.