Why should you be careful with Nginx's add_header directive?

Preface

As we all know, the nginx configuration file sets the response header by using the add_header directive.

Yesterday, I was bored and used curl to check the information of a site, and found that the returned header was different from what I expected:

HTTP/2 200
date: Thu, 07 Feb 2019 04:26:38 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding, Cookie
cache-control: max-age=3, must-revalidate
last-modified: Thu, 07 Feb 2019 03:54:54 GMT
X-Cache: Miss
server: cloudflare
...

The main site configures HSTS and other headers in nginx.conf:

add_header Strict-Transport-Security "max-age=63072000; preload";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

But the response header does not have these headers. In addition to the regular headers, there is only one header X-Cache configured in the location.

The first impression is that CDN filters these headers? So I looked for Cloudflare's documentation, but found no documentation on how to handle these. On second thought, why does CDN filter these? Are you bored because you've eaten too much? They don't do political inquiries!

The problem shifts to Nginx configuration. I opened Google and searched for "nginx location add_header", and indeed found quite a few flaws. Click on the official website add_header document, there is such a description (other information has been omitted):

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.

Note the emphasis on “These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.” That is, the parent settings will be inherited only if there is no add_header directive in the current level. So my question is clear: there is add_header in location, and the configuration in nginx.conf is discarded.

This is an intentional behavior of Nginx and cannot be called a bug or a pitfall. But if you take a deeper look at this sentence, you'll find a more interesting phenomenon: only the most recent add_header works. add_header can be configured in http, server and location, but the closest configuration will take effect, and the configuration above will be invalid.

But the problem doesn't end there. If the location is rewritten to another location, only the second header will appear in the final result. For example:

location /foo1 {
 add_header foo1 1;
 rewrite //foo2;
}

location /foo2 {
 add_header foo2 1;
 return 200 "OK";
}

Regardless of whether the request is /foo1 or /foo2, the final header is only foo2:

Although this makes sense and is normal behavior, it still feels a bit forced and uncomfortable: it's OK for the server to lose the http configuration and the location to lose the server configuration, but the two locations are at the same level!

If you cannot inherit the parent configuration and do not want to repeat the instructions in the current block, the solution is to use the include instruction.

refer to

• Nginx Module ngx_http_headers_module
• Nginx add_header configuration pitfall
• Be very careful with your add_header in Nginx! You might make your site insecure
• add_header directives in location overwriting add_header directives in server
• The pitfall of add_header in nginx configuration

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. If you have any questions, you can leave a message to communicate. Thank you for your support for 123WORDPRESS.COM.