Shulou(Shulou.com)06/02 Report--

It is believed that many inexperienced people have no idea about how to deal with the Nginx 405 not allowed exception. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Today, I encountered a problem. When the configured front-end project was started with nginx on the server, it reported a 405 Not allowed exception. Baidu said that the reason for this problem was due to the use of post requests to obtain static resources. I think it is very strange that the requested interfaces are all business interfaces, and there is no request for static resources. Is there any misunderstanding of nginx about static resources? In other words, I have a wrong understanding of static resources, and with this idea, I combed the concept of static resources again:

Static resources: refers to the js/css/jpg/png/xxx.json... in html And so on, these files need to be configured or compiled in advance in the front-end project, and these files do not change all the time or have a long period of change.

Solution attempt

OK, then I tried to try all the solutions based on Baidu. After all, there must be one that can solve so many solutions on the Internet, so I began to try all kinds of netizens' solutions:

Configure error_page in location. The solution to this problem is to convert post requests into get requests. The configuration information is as follows:

Server {listen 80; server_name domain name; location / {root / www/ file directory; index index.html index.htm index.php; error_page 405 = 200 http://$host$request_uri;}}

It is problematic to write in this way. Some netizens have mentioned that this writing is only applicable to requests without parameters in post requests. If post requests with parameters are used in this way, the parameter body may be lost.

two。 Modify the src/http/modules/ngx_http_static_module.c file under nginx as follows:

If (r-> method & NGX_HTTP_POST) {return NGX_HTTP_NOT_ALLOWED;}

The way to do this is to modify the source code of nginx, comment out this code, and recompile it. Note that you need to use / * * / instead of the # symbol when commenting, otherwise an error will be reported. Refer to this.

3. Modify the direction of the error interface (this method is widely circulated on the Internet, but the request method is not changed, so the following method is used). The code is as follows:

Upstream static_backend {server localhost:80;} server {listen 80; error_page 405 = 200 @ 405; location @ 405 {root / srv/http; proxy_method GET; proxy_pass http://static_backend;}

The idea is to redirect the error message of 405 to a location address named @ 405 and change the request method to the get method, which is the same as the first method above. This location resends the request to the static_backend,upstream defined in proxy_pass, which was originally used to configure the load balancer address. Here, a backend access address is directly given, so the idea is fine.

However, unfortunately, the above methods I have tried the first and the third, no effect on me, the second I will not try, I think nginx such a setting must have his reason, even through the modification of the source code to temporarily achieve the desired results, then this will also bring hidden dangers, will not upgrade nginx in the future, right? so I think modifying the source code is the most unreliable way.

Since none of these methods are effective, let's take a look at whether the log of the backend service has received a request. It turns out that after the backend service starts, it does not receive any request forwarding from Nginx, that is, all requests (including get) do not reach the background. At this time, I begin to suspect that it is the problem of location configuration. Why do you say so? because if it is a normal 405 not allowed exception. At least there is no problem with the get request, but after viewing the console and the backend service, it is found that the request has not been received at the backend. In the-network column of the browser console, the respone requested by get is a static page and is not the expected json data, as shown below:

The Headers column shows that the request is OK, as follows:

Based on this situation, I am more sure that the problem is not the 405 not allowed shown by it, but probably due to the abnormal configuration of location. Along this line of thinking, I reviewed the configuration of location. My original location configuration is as follows:

Location = / demo {# rewrite ^. + demo/? (. *) $/ $1 break; proxy_pass http://localhost:19998; proxy_set_header Host $host:$proxy_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; proxy_read_timeout 90 Proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;} location / {root / home/jenkins/workspace/demo-2.0/dist; try_files $uri $uri/ / index.html; proxy_redirect http:// https://; proxy_set_header Upgrade $http_upgrade Proxy_set_header Connection "upgrade";}

This is a strict matching pattern. There are 3 matching patterns in location. Refer to this. They are:

Location = patt {} [exact match]

Location patt {} [normal match]

Location ~ patt {} [regular match]

Among them, accurate matching has the highest priority-- > normal matching-- > regular matching.

Problem solving

I changed location = / demo {} to location / demo {} and solved the problem. Why?

Personally, precise matching needs to be specified to a specific access resource, such as location = / demo/index.html, which should be written this way. The url address requested in my post request is a long string of addresses, such as localhost:19999/demo/user/query, so it doesn't match / demo at all, but matches to the bottom location / {} So all the requests are sent to the main page, causing nginx to judge that all requests are requesting an index.html, which violates the design principle of nginx, that is, static files are not allowed to respond to POST requests, so there is a * * 404not allowed*** exception.

After reading the above, have you mastered how to handle Nginx 405 not allowed exceptions? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.