8 ms·

Adding GIT SHAs to your application's HTTP headers

59 points by andrewvc 16y ago

ulf 16y ago
Awesome. A real hack. Beautiful, simple, useful.
morganpyne 16y ago
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.
bradgessler 16y ago
Using a header isn't quite right. Just implement an URL on your app at /_revision that grabs the HEAD commit. Then write a git-diff-prod command like this: #!/bin/sh git-diff `curl -s "http://www.yourapp.com/_revision"` Get your paths squared away, chmod +x it, then type in: git diff-prod And boom! Instant diff with head in production. Of course, you might want to get your deploy scripts squared away for figure out why your servers aren't restarting if thats the reason for this.
- andrewvc 16y ago
  Yeah, that was the original reason I implemented it (since fixed), but I just found having it live was too useful to take away.
listrophy 16y ago
Neat, but kinda overkill to send it on every request. If you're doing Rails (as the article is), try out pig ( https://github.com/bendyworks/pig https://github.com/bendyworks/pig ) and go to /revision on your site. does not work with heroku since they strip the .git folder... we should probably add that to the readme
sophacles 16y ago
You know, the other day I was lamenting the sorry state that is caching on the web. I decided a pretty good protocol would be similar to this: make a standard http header that includes a SHA of the content for that url. That way if the content changes the SHA changes, and you get really good cache-ability without the worries of content timeout etc[1]. Further, cache control pragmas/headers/etc don't accidentally get misconfigured in a bad way. Caches just send a header request upstream and if the header hasn't changed, just blast the content on the presumably faster/cheaper local link. [1] They could still exist for hints or what not, but I presume reasonably advanced caches will be able to heuristically figure out how long the content lasts and do things like start sending results while waiting on the header to return... with some sort of reset if it turns out to be a bad cached result.
- prodigal_erik 16y ago
  Are you describing http://en.wikipedia.org/wiki/HTTP_ETag http://en.wikipedia.org/wiki/HTTP_ETag or something different?
  - sophacles 16y ago
    Apparently ETag, but you know, with people actually using it, and a standardized hashing mechanism (to reduce duplication of common elements across sites). (honestly I had never even heard of it before just now).
    - psadauskas 16y ago
      All browsers take advantage of it. Not very many library http clients do, though. (I had to write my own, https://github.com/paul/resourceful https://github.com/paul/resourceful )
    - riffraff 16y ago
      ommon elements are shared by using a single source (e.g. google's CDN for javascripts) but standardizing makes little sense imvho. For one, you can use an ETag without generating the page and hashing it if it only depends on a db-stored resource, and that is mightily application dependent.
dman 16y ago
So you have git installed in production?
- JonnieCache 16y ago
  A lot of people use git for deployment. It is also used during automatic dependency installation.
- jrockway 16y ago
  I bet he has "ls" also. The question is, "what's your point"?
  - emillon 16y ago
    If it is not necessary, don't install it. Rsync or scp is probably "good enough" for production.
    - jrockway 16y ago
      Apparently not if you want to include the git commit id in your HTTP headers :)
    - metageek 16y ago
      But git will let you do a diff to see if someone made manual changes.
  - dman 16y ago
    You can create a file with your git commit id in your deployment script and have it run on your source control box.
wulczer 16y ago
Sounds useful for early deployment stages, but later on you really should tag the code you deploy and perhaps include the tag in your application headers (or in the page footer, or somewhere). And even better, build packages after tagging in your VCS, which gives you numerous advantages, like being able to quickly check if someone modified the code in-place on the production machine.

59 points by andrewvc 16y ago

ulf 16y ago

Awesome. A real hack. Beautiful, simple, useful.

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.

bradgessler 16y ago

Using a header isn't quite right. Just implement an URL on your app at /_revision that grabs the HEAD commit. Then write a git-diff-prod command like this: #!/bin/sh git-diff `curl -s "http://www.yourapp.com/_revision"` Get your paths squared away, chmod +x it, then type in: git diff-prod And boom! Instant diff with head in production. Of course, you might want to get your deploy scripts squared away for figure out why your servers aren't restarting if thats the reason for this.

andrewvc 16y ago
Yeah, that was the original reason I implemented it (since fixed), but I just found having it live was too useful to take away.

listrophy 16y ago

Neat, but kinda overkill to send it on every request. If you're doing Rails (as the article is), try out pig ( https://github.com/bendyworks/pig https://github.com/bendyworks/pig ) and go to /revision on your site. does not work with heroku since they strip the .git folder... we should probably add that to the readme

sophacles 16y ago

You know, the other day I was lamenting the sorry state that is caching on the web. I decided a pretty good protocol would be similar to this: make a standard http header that includes a SHA of the content for that url. That way if the content changes the SHA changes, and you get really good cache-ability without the worries of content timeout etc[1]. Further, cache control pragmas/headers/etc don't accidentally get misconfigured in a bad way. Caches just send a header request upstream and if the header hasn't changed, just blast the content on the presumably faster/cheaper local link. [1] They could still exist for hints or what not, but I presume reasonably advanced caches will be able to heuristically figure out how long the content lasts and do things like start sending results while waiting on the header to return... with some sort of reset if it turns out to be a bad cached result.

prodigal_erik 16y ago
Are you describing http://en.wikipedia.org/wiki/HTTP_ETag http://en.wikipedia.org/wiki/HTTP_ETag or something different?
- sophacles 16y ago
  Apparently ETag, but you know, with people actually using it, and a standardized hashing mechanism (to reduce duplication of common elements across sites). (honestly I had never even heard of it before just now).
  - psadauskas 16y ago
    All browsers take advantage of it. Not very many library http clients do, though. (I had to write my own, https://github.com/paul/resourceful https://github.com/paul/resourceful )
  - riffraff 16y ago
    ommon elements are shared by using a single source (e.g. google's CDN for javascripts) but standardizing makes little sense imvho. For one, you can use an ETag without generating the page and hashing it if it only depends on a db-stored resource, and that is mightily application dependent.

dman 16y ago

So you have git installed in production?

JonnieCache 16y ago
A lot of people use git for deployment. It is also used during automatic dependency installation.
jrockway 16y ago
I bet he has "ls" also. The question is, "what's your point"?
- emillon 16y ago
  If it is not necessary, don't install it. Rsync or scp is probably "good enough" for production.
  - jrockway 16y ago
    Apparently not if you want to include the git commit id in your HTTP headers :)
  - metageek 16y ago
    But git will let you do a diff to see if someone made manual changes.
- dman 16y ago
  You can create a file with your git commit id in your deployment script and have it run on your source control box.

wulczer 16y ago

Sounds useful for early deployment stages, but later on you really should tag the code you deploy and perhaps include the tag in your application headers (or in the page footer, or somewhere). And even better, build packages after tagging in your VCS, which gives you numerous advantages, like being able to quickly check if someone modified the code in-place on the production machine.