Shulou(Shulou.com)05/31 Report--

This article mainly explains the "nginx configuration add_header pit how to solve", the article explains the content is simple and clear, easy to learn and understand, now please follow the editor's train of thought slowly in depth, together to study and learn "nginx configuration add_header pit how to solve" it!

Preface

Add_header is an instruction defined in the headers module, which, as its name implies, is used to add http response headers. But please note that he is just "adding", not rewriting. So if a header already exists, there will be a problem using add_header. And in earlier versions of nginx, add_header does not support use in error pages.

This is a command with a lot of holes. Its processing phase is later than location processing, and although it can be written in location, if the rewrite has another location, then the unprocessed add_header in the previous location will be lost. For example:

Location = / a {add_header a 1; rewrite / / b;} location = / b {add_header b 2; return 204;}

There is no A1 head, is there? This is a pit!

Another pit is the repetitive problem mentioned at the beginning. For example, I want to set content-type for a content, but because there is a default_type set globally, I repeat it.

Default_type 'text/plain';location = / a {add_header content-type application/json; return 200' "ok";}

Of course, there are many solutions, such as emptying the default_type for the location, or simply modifying the default_type for the location without using the add_header at all.

The last big hole is that it does not take effect on error pages, which is also clearly defined in. For example, the following example:

Location = / a {add_header content-type application/json; return 404'"not found";}

I want to respond to a json, but since the status code is 404, the add_header here doesn't work.

Although this example can be used to solve the problem with default_type, what if it is another head? What about access-control-allow-origin, for example? Then there is no solution except using lua or other third-party modules to solve the problem. Of course, nginx is aware of this problem, so the documentation also says that a parameter called always is supported after version 1.7.5. Although nginx has solved this problem on its own, tengine based on 1.6.2 is going to be ready.

Thank you for your reading, the above is the "nginx configuration add_header pit how to solve" the content, after the study of this article, I believe you on the nginx configuration add_header pit how to solve this problem have a deeper understanding, the specific use of the need for you to practice verification. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.