Nginx test in location priority!

LOCATION [= | ~ | ~ * | ^ ~] / uri / {...}
 
 = beginning exact matching
 ~ beginning represents a case-sensitive regular matching
 ~ * beginning indicates a case-insensitive regular matching
 ^ ~ beginning expressed uri to a a conventional start of the string, is understood to match the path to the url. url do not nginx coding, so the request is / static / 20 is % / AA, 
it may be regularly ~ ^ / static / / AA matched (note the space). ! ~ And! ~ * Are not case-sensitive and case-insensitive match does not match the regular / generic matches, any requests are matched. A case where a plurality of matching order configured for location: First match =, followed by matching ^ ~, followed by the positive matching file in order, finally to / generic matches. When there is a match success when stopped matching, processing requests by the current rule matches.

======================================================================================

Premise installed Nginx configuration file as follows :( emperor of compression and delay can be ignored)

user  nginx nginx;
worker_processes  2;
error_log  logs/error.log  info;
pid        logs/nginx.pid;
events {
   use epoll;
    worker_connections  10240;
}
http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                     '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;
    sendfile        on;
    server_tokens off;
    keepalive_timeout  65;
    client_header_timeout 60;
    client_body_timeout 60;
    gzip  on;
    gzip_buffers 4 16k;
    gzip_http_version 1.1;
    gzip_comp_level 2;
    gzip_types text/plain text/javascript application/x-javascrip t text/css text/xml
    application/xml application/xml+rss;
    server {
        listen       80;
        server_name  www.source.com;
        charset uft-8;
        access_log  logs/source.com.access.log  main;
测试区
location / { return 400; } location /test { return 401; }
        location  ~ ^/test {
                    return 402;
}

        location ~ ^/test/aaa {
          return 403;
}




}
}

After each modifying the master configuration file must perform the following two commands:

[root@localhost ~]# nginx -t
[root@localhost ~]# killall -HUP nginx                               //重启nginx

Testing theories : deliberately put a low priority location earlier, to see whether it is because linux on from the match and the next match lead to disorder

First Test : Test the priority of the plurality of Wild added location / test

[root@localhost conf]# curl -v 127.0.0.1:80/test

< HTTP/1.1 401 Unauthorized

Test results : / test higher priority than location /

Second test : location regular priority test, we add ^ ~ / test, use a regular match with the beginning of the test

[root@localhost ~]# curl -v 127.0.0.1:80/test

< HTTP/1.1 402 Payment Required

Test Results : ~ ^ / test with high priority / test, that is a regular location is greater than the priority of wild location

Third Test : more regular priority test, we used two regular, mainly to validate the next, is not the more regular configuration, the higher the priority.

[root@localhost ~]# curl -v 127.0.0.1:80/test/aaa

< HTTP/1.1 402 Payment Required

Test results : 402 results returned, which is the first positive after the match to, will not go under the regular match. Since the request / test / aaa, hit ^ / test, so under regular is invalid

Fourth Test : We join precise match, that is, the nginx =, our next test match precisely the priority

[root@localhost ~]# curl -v 127.0.0.1:80/test/aaa

< HTTP/1.1 404 Not Found

Test results: Return 404. This explains, precisely matching = highest priority , regardless of where it is placed.

 

Guess you like

Origin www.cnblogs.com/cxm123123form/p/11539809.html