Remove unnecessary HTTP headers in my rails answers - ruby-on-rails

Question

I am currently developing an API where size matters: I want the answer to contain as few bytes as possible. I optimized my JSON answer, but rails still responds with many strange headers
HTTP/1.1 200 OK
Server: nginx/0.7.67 # Not from Rails, so ok.
Date: Wed, 25 Apr 2012 20:17:21 GMT # Date does not matter. We use ETag Can I remove this?
ETag: "678ff0c6074b9456832a710a3cab8e22" # Needed.
Content-Type: application/json; charset=utf-8 # Also needed.
Transfer-Encoding: chunked # The alternative would be Content-Length, so ok.
Connection: keep-alive # Good, less TCP overhead.
Status: 200 OK # Redundant! How can I remove this?
X-UA-Compatible: IE=Edge,chrome=1 # Completely unneded.
Cache-Control: no-cache # Not needed.
X-Request-Id: c468ce87bb6969541c74f6ea761bce27 # Not a real header at all.
X-Runtime: 0.001376 # Same goes for this
X-Rack-Cache: invalidate, pass # And this.
So there are lots of unnecessary HTTP headers. I could filter them in my server (nginx), but is there a way stop this directly in rails?

Answer 1

You can do this with a piece of Rack middleware. See https://gist.github.com/02c1cc8ce504033d61bf for an example of to do it in one.
When adding it to your app config, use something like config.middleware.insert_before(ActionDispatch::Static, ::HeaderDelete)
You want to insert it before whatever the first item in the list that displays when you run rake middleware, which in my case is ActionDispatch::Static.
http://guides.rubyonrails.org/rails_on_rack.html may be somewhat helpful if you haven't been exposed to Rack in the Rails context before.

Answer 2

Another option, since you're using Nginx, is the HttpHeadersMoreModule. This will allow you to have fine-grain control of exactly which headers are sent down the wire.
In your case, you'd specifically want to use the more_clear_headers directive, as such:
more_clear_headers Server Date Status X-UA-Compatible Cache-Control X-Request-Id X-Runtime X-Rack-Cache;
This also clears the Server header, since it's not really necessary, and if you're trying to save bytes, every little bit helps.
This module does require you to compile Nginx on your own, but that really shouldn't scare you. Nginx is very easy to compile, just follow the installation instructions.

Answer 3

I agree that both solutions presented by x1a4 and Stephen McCarth are good.
Ideally you should definitely use the HttpHeadersMoreModule however if someone is fan of native Ubuntu NginX package with security updates like I am, (or you don't have time for that, or just lazy) you don't necessary need to do that.
Another way is to use proxy_hide_header
server {
location #unicorn {
# ...
proxy_hide_header X-Powered-By;
proxy_hide_header X-Runtime;
# ...
}
}
note: #unicorn is just upsteram server, the location can be whatever /, /assets, ..
Now one argument against this solution is if you use several server blocks inside configuration that you need to specify proxy_hide_header to each one of them. Well yes but you can just create file and include it
# /etc/nginx/sites-enabled/my_app
server {
location #unicorn {
# ...
include /etc/nginx/shared/stealth_headers
# ...
}
}
# /etc/nginx/shared/stealth_headers
proxy_hide_header X-Powered-By;
proxy_hide_header X-Runtime
So why I think this solution is better than to use the middle-ware solution as presented by x1a4 ?
I had similar middle-ware solution before and it was working fine for couple of months. Then one day we stopped receiving Exception errors by exception monitoring tool party_foul gem. Long story short Middlewares are tricky, we done some code changes and this middleware was throwing exception, but it was throwing exception that was not caught with middleware that was suppose to monitor exceptions. So yes the whole thing is my bad, I should keep better eye on my code not doing stupid stuff, hewever I had unpleasant experience that is hard to erase, so I'm just recommending if you can rather to handle this on NginX level, not on middle-ware level
+ it make more sence if your NginX is handling several configurations (you don't have to update several applications if some change)