0

I'm configuring an application that will authenticate a user, and then set the X-Accel-Redirect header and a private api key, Foo (for testing purposes), that will be passed on to the proxied endpoint.

I'm setting the private api key as a header in the authenticating application, and have the following location block in my nginx configuration file. How do I set the header to the proxied application based on what the upsteam server sets? I've also tried using $http_foo and $sent_http_foo. Currently, the Foo response header is never set for the proxy.

location ~* ^/redirect {
  internal;

  resolver 8.8.8.8;
  proxy_ssl_server_name on;
  add_header Foo $upstream_http_foo;

  set $my_host "requestb.in";
  set $my_uri "a_test_uri";
  proxy_pass http://$my_host/$my_uri;
}
benkhicks
  • 1
  • 2

1 Answers1

3

The directive to use is proxy_set_header, so in your case:

proxy_set_header Foo $http_api_key; # assuming a "API-Key" header incoming

As a general rule, any settings you intend to apply to your communication with an upstream will be prefixed with proxy_

Joshua DeWald
  • 3,079
  • 20
  • 16
  • Ah ok, using `proxy_set_header` makes sense, thanks. What is the appropriate variable to use to get the value of the Foo header set by my application in this case? When I use `$foo_value`, I get the following error: nginx: [emerg] unknown "foo_value" variable – benkhicks Aug 04 '16 at 14:55
  • It really depends on how it is incoming. I updated to reference an "API-Key" http header. Any headers should already automatically go through the proxy, so if you were passing "Foo" in the inbound request, it would also end up going to the proxied server without the need to do a `proxy_set_header` – Joshua DeWald Aug 04 '16 at 16:04
  • In my case, the header will be set on the upstream server, the application that is authenticating the request and also setting the `X-Accel-Redirect` header. I tried the `$http_api_key` header and it did not populate on the proxy. – benkhicks Aug 04 '16 at 17:59
  • http_api_key is just an example, it depends on what specifically you are getting, replace it with whatever parameter you are expecting to get from the incoming request. – Joshua DeWald Aug 04 '16 at 21:17
  • Thanks for your suggestions. It appears that the `proxy_pass` directive inside the location overrides the `$upstream_http_` variables set by the application. The solution that worked for me is to have an intermediary location which stores the `$upstream_http_foo` variable, and then rewrite to the location that has the `proxy_pass` directive (https://groups.google.com/forum/#!topic/openresty-en/vPxQFntAfCc). – benkhicks Aug 05 '16 at 14:58
  • The `$upstream_` variables are what you get *from* the proxy, seems odd that they would be getting overwritten. Perhaps I'm not understanding your goal (which I thought was to send *to* the proxy). – Joshua DeWald Aug 05 '16 at 16:14
  • @JoshuaDeWald Would the header name here be `API-Key` or `API-KEY`? From the nginx documentation for `$http_` variables: "arbitrary request header field; the last part of a variable name is the field name converted to lower case with dashes replaced by underscores". The doc can be found [here](http://nginx.org/en/docs/http/ngx_http_core_module.html#var_http_) – kapad Aug 22 '18 at 06:41
  • @kapad It wouldn't really matter, both would resolve to `$http_api_key` when looking up the value. HTTP headers should be case insensitive (even though they are usually thought in terms of things like "Content-Type"). For example, if the request came over http/2, it will be fully lowercase when it arrives in nginx (all http/2 headers are lowercase). – Joshua DeWald Aug 23 '18 at 15:14
  • @JoshuaDeWald okay thanks. I didn't realise this. For any one else, see [this](https://stackoverflow.com/questions/5258977/are-http-headers-case-sensitive) answer which deals with case sensitivity of HTTP headers and links to the respective RFCs. – kapad Aug 27 '18 at 11:44