3 ms·

While it's a neat little trick, I'm not so sure I like this. This is adding unnecessary headers and traffic overhead. It doesn't even addresses some of the poin

While it's a neat little trick, I'm not so sure I like this. This is adding unnecessary headers and traffic overhead. It doesn't even addresses some of the points the author mentioned e.g. "someone deployed something in a weird way and bypassed the normal deployment process" (if somebody is doing this you have bigger problems anyway). If you are managing your releases in a sensible and automated way then you will also typically have an easy way to check which version is currently deployed or running which doesn't involve adding more baggage to the HTTP headers.

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 ago
  That'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 ago
    I'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.

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 ago
That'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 ago
  I'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.