Opened 8 years ago

Closed 8 years ago

#823 closed enhancement (wontfix)

Add disable_header option (opposite of add_header) which would let apps (php, ..) to control their headers

Reported by: arno01@… Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.9.x
Keywords: headers, add_header, disable_header, control Cc:
uname -a: Linux www 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.9.6
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6


Dear devs,

I think it would be nice to have "disable_header" option.

To give you an idea what I mean, I will give you an example.
In my particular case I am using Piwik (open source analytics solution) which always adds "X-Frame-Options".
Here is the owner's response which says that this header should be controlled by the webserver only (I believe there are more such pieces of SW that add their own extra headers)

I am okay with switching this header off in the nginx config and letting the Piwik to take the control of it, unfortunately I have the "X-Frame-Options" header set in a global config for all my vhosts (somehwere in conf.d/*.conf, my vhosts are in vhosts/*.conf) which gives me only way to split the headers among the vhost files and this is not something I want.

It would be nice to have the application-level headers control as well, and even mixed (some headers to be set by the nginx and some - by the app). Therefore I suggest to add "disable_header" flag. (or it can be named as "exclude_header" or "except_header", ...)

(an extra idea) "disable_header" could be also wildcard'ed, I bet someone would find this useful. (wildcard use case example "disable_header X-*;")

If you see my point, I would be happy to see this feature in the coming release!

Change History (6)

comment:1 by arno01@…, 8 years ago

There is another problem, when I am adding "add_header" to some of vhosts (vhosts/*.conf), then it automatically drops all the headers which are set by the global config (conf.d/*.conf) ... I do not think it should be this way.

Last edited 8 years ago by arno01@… (previous) (diff)

comment:2 by Maxim Dounin, 8 years ago

Resolution: wontfix
Status: newclosed

If you don't want nginx to add a header in a particular server/location, you can overwrite add_header directives set at higher levels by introducing at least one add_header directive at a given level, quoting docs:

There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.

Such behaviour allows to effectively redefine headers added where needed, while preserving global/inherited values for most of the configuration. Note well that such a behaviour is consistent across all nginx directives.

comment:3 by arno01@…, 8 years ago

Resolution: wontfix
Status: closedreopened

This is exactly the opposite of what I want, thus I have tried to describe my situation clearer.
I do not want a single 'add_header', placed at the lower level, discard the top level headers. This does not even follow the logic of a word "add", IMHO.

For example, I have HTTP Public Key Pinning (HPKP) set at the top level so that it is applied to all my vhosts.

IMHO, it is normal to control it over there in one file, instead of discarding all the headers because of the one single 'add_header' placed at the lower level.

In other words if I have 'Strict-Transport-Security', 'Public-Key-Pins', 'X-Frame-Options', 'X-XSS-Protection' and 'X-Content-Type-Options' set at the top level configuration file, why would I want to discard all of them "just" by _adding_ a single 'X-Robots-Tag' header at the lower level? This creates duplication problem which leads to more complex configuration management, where one needs to keep in mind that there are certain headers in some of the vhosts which discard the main top-level headers config file.

Last edited 8 years ago by arno01@… (previous) (diff)

comment:4 by Valentin V. Bartenev, 8 years ago

Resolution: fixed
Status: reopenedclosed

Almost all directives in nginx are based on this principle. The practice shows that it actually simplifies the configuration management, because you should think less and just copy'n'paste.

For more information, please, see:

Last edited 8 years ago by Valentin V. Bartenev (previous) (diff)

comment:5 by Maxim Dounin, 8 years ago

Resolution: fixed
Status: closedreopened

comment:6 by Maxim Dounin, 8 years ago

Resolution: wontfix
Status: reopenedclosed
Note: See TracTickets for help on using tickets.