Nginx – Is it good practice to set HTTP headers in the load balancer

Architecturebest practiceshttp-headersnginx

I am managing a setup where there are two ngnix application servers behind an nginx reverse proxy. I would like to set some headers like X-XSS-Protection or Strict-Transport-Security. Currently, it's set on both application servers and the load balancer and this is causing headers to be convoluted.

Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied.

I can see that the duplicate header values are being appended to the same header key. My question is this: What's the general convention/accepted best practice for setting headers? Should I set headers in the backend and remove them from the load balancer or should the load balancer be the one setting headers?

Best Answer

In my opinion it doesn't matter where headers are set. The advantage of setting headers in Nginx is they're really quite simple to change, compared with changing code, deploying, etc. I've had two cases where I've had to rewrite headers using either Nginx or an F5 load balancer, they give a lot more flexibility.

You would need to give a more concrete example to get more useful information, as your question is too broad.

Related Solutions

Nginx – Poor load balancer performance on rackspace and centos

I am also on Rackspace Cloud and I have a very similar issue. I believe the problem is this:

Rackspace Cloud Server FAQ

It would appear from what you are describing you are simply maxing out the pitiful amounts of bandwith rackspace gives us, almost entirely making all of the amazing performance gains things like Varnish/Nginx provide.

To confirm, re-run some of your benchmarks with iftop open, and watch it totally cap out to the amounts rackspace provides at each server size.

Nginx – Block User Based on X Header Value

That's easy. Nginx's "geo" module lets define a variable with value depending on the client's IP address:

geo $ban_ip {
  default 0;
  10.1.0.0/24 1;
};

geo directive should be at http level (e.g. outside server). There is a convenient way to include large IP databases via include or ranges, see the documentation

So, assuming you have such a variable, you may return whatever status codes you'd like, e.g. 403 or 404 (at server level or in location):

if ($ban_ip) {
  return 403;
}

If you'd like to silently drop the connection, use

if ($ban_ip) {
  return 444;
}

444 is a non-standard status code used internally to instruct Nginx to drop the connection. (thus a client does not see it)

Best Answer

Related Solutions

Nginx – Poor load balancer performance on rackspace and centos

Nginx – Block User Based on X Header Value

Related Topic