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…
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?
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. 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.