Add_header isn't taking effect

This block basically works like a charm, passes the upstream headers
from proxy_pass_header as expected, but the add_header doesn’t seem to
work no matter what. add_header is what I use upstream to add the
headers like X-Hostname-Proxy.

But I want to add a header local to this block. Ideas? I don’t see
anything in the wiki saying this is invalid. It says it is valid in
location, server, etc blocks, which is what this is… :stuck_out_tongue:

location ^~ /foo/bar {
proxy_pass http://sites:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass_header Server;
proxy_pass_header Expires;
proxy_pass_header X-Hostname-Proxy;
proxy_pass_header Access-Control-Allow-Origin;
add_header FOO “bar”;
add_header FOO2 bar2;
}

On Sat, Aug 18, 2012 at 03:44:05PM -0700, Michael S. wrote:

Hi there,

This block basically works like a charm, passes the upstream headers
from proxy_pass_header as expected, but the add_header doesn’t seem to
work no matter what. add_header is what I use upstream to add the
headers like X-Hostname-Proxy.

It seems to work for me. Perhaps my test case is not the same as your
test case.

What request do you make; what response do you get; and what response
do you expect to get?

f

Francis D. [email protected]

It actually seems like if I add_header in one scope somewhere it will
ignore in another.

For example I have one gratuitous add_header at the server {} level -
with a different name.

Then I add one on the location level.

Then I have one come from the upstream.

I could reproduce it reliably by adding an add_header somewhere and it
would drop the other one out. I also have two environments with nearly
exact configurations and one passes all 3 headers I want vs. 2 headers
consistently. Very odd.

On Sat, Aug 18, 2012 at 4:46 PM, Francis D. [email protected]
wrote:

In this location, only this one will apply. In another location, only
the server-level one will apply.

I expected add_header to be an array item, which it might be, but I
guess I forgot how nginx scope worked.

I wish the scope would be a little looser (something that makes sense
from someone who writes scripts in PHP for a living)

I just got done reading that blog post (source I am too lazy to look
up) explaining scope on variables, and got bit by fastcgi_param scope
in the past the same way.

Oh well. :slight_smile: It is odd that I get inconsistent results and I do seem
to get multiple headers coming through sometimes it seems, even though
it doesn’t make sense from the scope level.

On Sat, Aug 18, 2012 at 04:31:54PM -0700, Michael S. wrote:

Hi there,

It actually seems like if I add_header in one scope somewhere it will
ignore in another.

Yes, that’s the expected behaviour for nginx configuration directives.

A request is handled in exactly one location; the configuration in or
inherited into that location is what matters; inheritance or merging is
by replacement.

For example I have one gratuitous add_header at the server {} level -
with a different name.

Then I add one on the location level.

In this location, only this one will apply. In another location, only
the server-level one will apply.

Then I have one come from the upstream.

nginx doesn’t care about headers being added; it cares about the
add_header directive. So this line should not influence the outcome.

I could reproduce it reliably by adding an add_header somewhere and it
would drop the other one out. I also have two environments with nearly
exact configurations and one passes all 3 headers I want vs. 2 headers
consistently. Very odd.

I suspect that if you compare the nearly exact configurations, you’ll
spot an important difference.

If you want a specific extra add_header in a location, you must also
repeat the other add_header directives within that location.

f

Francis D. [email protected]