location matching order 1. "=" prefix instruction matching, if the match is successful, stop other matching Note 1. The matching order is to match the normal string first, and then match the regular expression. In addition, the order of common string matching is from long to short according to the length of characters in the configuration. That is to say, the order of locations configured with common strings is irrelevant. In the end, nginx will match according to the length of the configuration. However, it should be noted that regular expressions are tested in the order in the configuration file. The search stops when the first match of the regular expression is found. 2. In general, after successfully matching the ordinary string location, the regular expression location will also be matched. There are two ways to change this behavior. One is to use the "=" prefix, which performs a strict match and stops other matches immediately after a successful match while processing the request. The other is to use the "^~" prefix. If this prefix is used for a regular string, it tells nginx not to test the regular expression if the path matches. Matching pattern and order Location = /uri = at the beginning indicates an exact match, and only a complete match will take effect. location ^~ /uri ^~ starts with a prefix match on the URL path and comes before the regular expression. The location ~ pattern ~ at the beginning indicates a case-sensitive regular match. location ~* pattern ~* starts with a case-insensitive regular expression. location /uri without any modifiers also indicates prefix matching, but after regular expression matching. location / Universal matching, any request that does not match other locations will be matched, which is equivalent to the default in switch. Experimental Case Test "^~" and "~", nginx configuration is as follows. Enter http://localhost/helloworld/test in the browser and it returns 601. If you comment #1 and open #2, and enter http://localhost/helloworld/test in the browser, 603 will be returned. Note: #1 and #2 cannot be opened at the same time. If they are opened at the same time, when starting nginx, it will report nginx: [emerg] duplicate location "/helloworld"..., because these two are ordinary strings. location ^~ /helloworld { #1 return 601; } #location /helloworld { #2 # return 602; #} location ~ /helloworld { return 603; } Test the length of a common string (the matching of a common string has nothing to do with the order but with the length). Enter http://localhost/helloworld/test/a.html in the browser and it returns 601. Enter http://localhost/helloworld/a.html in the browser and it returns 602. location /helloworld/test/ { #1 return 601; } location /helloworld/ { #2 return 602; } Test the order of regular expressions (regular matching is order-dependent). Enter http://localhost/helloworld/test/a.html in the browser, and return 602; swap the order of #2 and #3, enter http://localhost/helloworld/test/a.html in the browser, and return 603 location /helloworld/test/ { #1 return 601; } location ~ /helloworld { #2 return 602; } location ~ /helloworld/test { #3 return 603; } So in actual use, I think there are at least three matching rule definitions, as follows: #Directly match the website root. It is more frequent to access the website homepage through the domain name. Using this will speed up the processing, the official website said. #This is forwarded directly to the backend application server, or it can be a static homepage# The first required rule location = / { proxy_pass http://tomcat:8080/index } # The second mandatory rule is to process static file requests, which is the strength of nginx as an http server. # There are two configuration modes, directory matching or suffix matching, choose one or use both location ^~ /static/ { root /webroot/static/; } location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ { root /webroot/res/; } #The third rule is a general rule, which is used to forward dynamic requests to the backend application server. #Non-static file requests are dynamic requests by default, and you can grasp it according to your actual situation. #After all, some popular frameworks now rarely have .php and .jsp suffixes. location / { proxy_pass http://tomcat:8080/ } The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM. You may also be interested in:
|
<<: React+Antd implements an example of adding, deleting and modifying tables
>>: Install MySQL 5.7.18 using rpm package under CentOS 7
Table of contents docker system df docker system ...
Cluster Deployment Overview 172.22.12.20 172.22.1...
Table of contents 1. Variables Use meaningful nam...
Table of contents 1. The role of array: 2. Defini...
The browser is probably the most familiar tool fo...
Preface: I encountered a requirement to extract s...
The server reports an error 502 when synchronizin...
Look at the solution first #------------The probl...
Table of contents Introduction to bootstrap and i...
This article example shares the specific code for...
Table of contents 1. ES syntax getter and setter ...
1. Check the firewall status Check the firewall s...
Recorded the download and installation tutorial o...
Checkboxes are very common on web pages. Whether ...
Table of contents Summary put first: 🌲🌲 Preface: ...