Preface
As we all know, the nginx configuration file sets the response header by using the add_header directive.
Use curl to check the information of a site and find that the returned header is different from what was 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 has configured 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 I didn't find that it would handle these. Then I thought about it, what does CDN do to filter these? Are you full after eating? They don't do the censorship thing!
The problem shifts to the configuration of nginx. Open Google and search for "nginx location add_header", and you will find many flaws. Click on the add_header document on the official website and there is this 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.
Attention is focused 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 a deliberate behavior of nginx, and it cannot be said to be a bug or a pit. But if you understand this sentence deeply, you will find a more interesting phenomenon: only the latest add_header works. add_header can be configured in http, server and location, but the closest configuration will take effect, and all configurations above will be invalid.
But the problem doesn’t stop 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 requesting /foo1 or /foo2, the final header is only foo2:
Although it makes sense, this is normal behavior, but it always makes people It feels a bit forced and uncomfortable: the server loses the http configuration, and the location loses the server configuration, but the two locations are at the same level!
You cannot inherit the parent configuration, and you don’t want to repeat instructions in the current block. The solution can be to use the include instruction.
The above is the detailed content of Nginx add_header instruction example analysis. For more information, please follow other related articles on the PHP Chinese website!

NGINXUnit is an open source application server that supports multiple programming languages and provides functions such as dynamic configuration, zero downtime updates and built-in load balancing. 1. Dynamic configuration: You can modify the configuration without restarting. 2. Multilingual support: compatible with Python, Go, Java, PHP, etc. 3. Zero downtime update: Supports application updates that do not interrupt services. 4. Built-in load balancing: Requests can be distributed to multiple application instances.

NGINXUnit is better than ApacheTomcat, Gunicorn and Node.js built-in HTTP servers, suitable for multilingual projects and dynamic configuration requirements. 1) Supports multiple programming languages, 2) Provides dynamic configuration reloading, 3) Built-in load balancing function, suitable for projects that require high scalability and reliability.

NGINXUnit improves application performance and manageability with its modular architecture and dynamic reconfiguration capabilities. 1) Modular design includes master processes, routers and application processes, supporting efficient management and expansion. 2) Dynamic reconfiguration allows seamless update of configuration at runtime, suitable for CI/CD environments. 3) Multilingual support is implemented through dynamic loading of language runtime, improving development flexibility. 4) High performance is achieved through event-driven models and asynchronous I/O, and remains efficient even under high concurrency. 5) Security is improved by isolating application processes and reducing the mutual influence between applications.

NGINXUnit can be used to deploy and manage applications in multiple languages. 1) Install NGINXUnit. 2) Configure it to run different types of applications such as Python and PHP. 3) Use its dynamic configuration function for application management. Through these steps, you can efficiently deploy and manage applications and improve project efficiency.

NGINX is more suitable for handling high concurrent connections, while Apache is more suitable for scenarios where complex configurations and module extensions are required. 1.NGINX is known for its high performance and low resource consumption, and is suitable for high concurrency. 2.Apache is known for its stability and rich module extensions, which are suitable for complex configuration needs.

NGINXUnit improves application flexibility and performance with its dynamic configuration and high-performance architecture. 1. Dynamic configuration allows the application configuration to be adjusted without restarting the server. 2. High performance is reflected in event-driven and non-blocking architectures and multi-process models, and can efficiently handle concurrent connections and utilize multi-core CPUs.

NGINX and Apache are both powerful web servers, each with unique advantages and disadvantages in terms of performance, scalability and efficiency. 1) NGINX performs well when handling static content and reverse proxying, suitable for high concurrency scenarios. 2) Apache performs better when processing dynamic content and is suitable for projects that require rich module support. The selection of a server should be decided based on project requirements and scenarios.

NGINX is suitable for handling high concurrent requests, while Apache is suitable for scenarios where complex configurations and functional extensions are required. 1.NGINX adopts an event-driven, non-blocking architecture, and is suitable for high concurrency environments. 2. Apache adopts process or thread model to provide a rich module ecosystem that is suitable for complex configuration needs.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.

Dreamweaver CS6
Visual web development tools

SAP NetWeaver Server Adapter for Eclipse
Integrate Eclipse with SAP NetWeaver application server.

SublimeText3 Linux new version
SublimeText3 Linux latest version

SublimeText3 Mac version
God-level code editing software (SublimeText3)
