Opened 9 years ago
Closed 9 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: | 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/nginx.pid --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 |
||
Description
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 https://github.com/piwik/piwik/issues/7379#issuecomment-133149429 (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:2 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
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_headerdirectives. These directives are inherited from the previous level if and only if there are noadd_headerdirectives 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 , 9 years ago
| Resolution: | wontfix |
|---|---|
| Status: | closed → reopened |
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.
comment:4 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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:
https://www.youtube.com/watch?v=YWRYbLKsS0I
https://blog.martinfjordvald.com/2012/08/understanding-the-nginx-configuration-inheritance-model/
comment:5 by , 9 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:6 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | reopened → closed |
There is another problem, if 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.