[Bug]: add_headers from multiple layers not getting merged

[dhatri308]

Version

3.7.1

What Kubernetes platforms are you running on?

Openshift

Steps to reproduce

We have a main nginx and then bunch of Ingresses.
I tried adding custom if blocks in main nginx configmap location-snippets to add some headers conditionally.
While some of the Ingress resources did get this config but some did not.
Then I noticed that the Ingresses that did not get this change from main nginx configmap had their own location-snippets and that had a higher precedence than the main nginx's configmap's location-snippets.

I was hoping that the location-snippets from both layers would get merged but looks like that is not the case. Is this behavior expected ?

If I add the custom if blocks in Ingress location-snippets, the add_headers in http_context from main nginx gets masked. I was hoping that the headers from both would get merged. Is this an issue in nginx or works as expected ?

location / {
    # This block adds the necessary CORS headers if the Origin header is present
    if ($http_origin ~* "^https?://([a-z0-9-]+\.)*foobar\.com$") {
        add_header 'Access-Control-Allow-Origin' "$http_origin" always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
    }
 
    # Handle preflight OPTIONS requests
    if ($request_method = OPTIONS ) {
        add_header 'Access-Control-Allow-Origin' "$http_origin" always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        add_header 'Content-Length' 0;
        return 204;
    }
}

[github-actions]

Hi @dhatri308 thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

[vepatel]

hi @dhatri308 , lower level directives usually takes precedence over top level (if defined in both contexts). In order to preserve it, you must redefine them in lower contexts.
see https://www.f5.com/company/blog/nginx/avoiding-top-10-nginx-configuration-mistakes#directive-inheritance for more info

[dhatri308]

@vepatel thank you for your response.
I have a couple of questions

1. Is it possible to define a group of headers and assign them to a variable for reuse in multiple contexts?

Due to how directive inheritance works, there is a scenario where we must set add_header directives in the http context for Ingresses that do not include add_header directives in their server or location snippets. Additionally, we need to apply the same set of headers for Ingresses that already use server/location snippets and also include add_header directives.

2. Suppose we have a Nginx configmap with location-snippets that have add_header directives and we have an Ingress resource with location-snippets but NO add_header directives, should we not expect to see add_header directives get added to Ingress resource locations by inheritance or does the Ingress location-snippets completely conceal the Nginx configmap's location-snippets ?

3. Further down in the article, it’s mentioned that using "if" is generally discouraged. Could you please recommend an alternative approach to achieve this functionality without using if?

Thank you.

[danielnginx]

@dhatri308, this is a NGINX configuration question. Could you please ask your question in the NGINX Community Forum https://community.nginx.org/