Nginx 关于 location 的匹配规则详解

有些童鞋的误区

1 location 的匹配顺序是“先匹配正则,再匹配普通”。

矫正: location 的匹配顺序其实是“先匹配普通,再匹配正则”。我这么说,大家一定会反驳我,因为按“先匹配普通,再匹配正则”解释不了大家平时习惯的按“先匹配正则,再匹配普通”的实践经验。这里我只能暂时解释下,造成这种误解的原因是:正则匹配会覆盖普通匹配(实际的规则,比这复杂,后面会详细解释)。

2 location 的执行逻辑跟 location 的编辑顺序无关。

矫正:这句话不全对,“普通 location ”的匹配规则是“最大前缀”,因此“普通 location ”的确与 location 编辑顺序无关;但是“正则 location ”的匹配规则是“顺序匹配,且只要匹配到第一个就停止后面的匹配”;“普通 location ”与“正则 location ”之间的匹配顺序是?先匹配普通 location ,再“考虑”匹配正则 location 。注意这里的“考虑”是“可能”的意思,也就是说匹配完“普通 location ”后,有的时候需要继续匹配“正则 location ”,有的时候则不需要继续匹配“正则 location ”。两种情况下,不需要继续匹配正则 location :( 1 )当普通 location 前面指定了“ ^~ ”,特别告诉 Nginx 本条普通 location 一旦匹配上,则不需要继续正则匹配;( 2 )当普通 location 恰好严格匹配上,不是最大前缀匹配,则不再继续匹配正则。

总结一句话:“正则 location 匹配让步普通 location 的严格精确匹配结果;但覆盖普通 location 的最大前缀匹配结果”

官方文档解释

REFER:  http://wiki.nginx.org/NginxHttpCoreModule#location

location

syntax: location [=|~|~*|^~|@] /uri/ { … }

default: no

context: server

This directive allows different configurations depending on the URI.

(译者注:1 、different configurations depending on the URI 说的就是语法格式:location [=|~|~*|^~|@] /uri/ { … } ,依据不同的前缀“= ”,“^~ ”,“~ ”,“~* ”和不带任何前缀的(因为[A] 表示可选,可以不要的),表达不同的含义, 简单的说尽管location 的/uri/ 配置一样,但前缀不一样,表达的是不同的指令含义。2 、查询字符串不在URI 范围内。例如:/films.htm?fid=123 的URI 是/films.htm 。)

It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

1.”~” for case sensitive matching

2.”~*” for case insensitive matching

译文:上文讲到location /uri/ 可通过使用不同的前缀,表达不同的含义。对这些不同前缀,分下类,就2 大类:正则location ,英文说法是location using regular expressions 和普通location ,英文说法是location using literal strings 。那么其中“~ ”和“~* ”前缀表示正则location ,“~ ”区分大小写,“~* ”不区分大小写;其他前缀(包括:“= ”,“^~ ”和“@ ”)和无任何前缀的都属于普通location 。

To determine which location directive matches a particular query, the literal strings are checked first.

译文:对于一个特定的 HTTP 请求( a particular query ), nginx 应该匹配哪个 location 块的指令呢(注意:我们在 nginx.conf 配置文件里面一般会定义多个 location 的)?匹配 规则是:先匹配普通location (再匹配正则表达式)。注意:官方文档这句话就明确说了,先普通location ,而不是有些同学的误区“先匹配正则location ”。

Literal strings match the beginning portion of the query – the most specific match will be used.

前面说了“普通location ”与“正则location ”之间的匹配规则是:先匹配普通location ,再匹配正则location 。那么,“普通location ”内部(普通location 与普通location )是如何匹配的呢?简单的说:最大前缀匹配。原文:1 、match the beginning portion of the query (说的是匹配URI 的前缀部分beginning portion ); 2 、the most specific match will be used (因为location 不是“严格匹配”,而是“前缀匹配”,就会产生一个HTTP 请求,可以“前缀匹配”到多个普通location ,例如:location /prefix/mid/ {} 和location /prefix/ {} ,对于HTTP 请求 /prefix/mid/t.html ,前缀匹配的话两个location 都满足,选哪个?原则是:the most specific match ,于是选的是location /prefix/mid/ {} )。

Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search.

这段话说了两层意思,第一层是:“Afterwards, regular expressions are checked ”, 意思是普通location 先匹配,而且选择了最大前缀匹配后,不能就停止后面的匹配,最大前缀匹配只是一个临时的结果,nginx 还需要继续检查正则location (但至于最终才能普通location 的最大前缀匹配,还是正则location 的匹配,截止当前的内容还没讲,但后面会讲)。第二层是“regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. ”,意思是说“正则location ”与“正则location ”内部的匹配规则是:按照正则location 在配置文件中的物理顺序(编辑顺序)匹配的(这句话就说明location 并不是一定跟顺序无关,只是普通location 与顺序无关,正则location 还是与顺序有关的),并且只要匹配到一条正则location ,就不再考虑后面的(这与“普通location ”与“正则location ”之间的规则不一样,“普通location ”与“正则location ”之间的规则是:选择出“普通location ”的最大前缀匹配结果后,还需要继续搜索正则location )。

If no regular expression matches are found, the result from the literal string search is used.

这句话回答了“普通location ”的最大前缀匹配结果与继续搜索的“正则location ”匹配结果的决策关系。如果继续搜索的“正则location ”也有匹配上的,那么“正则location ”覆盖 “普通location ”的最大前缀匹配(因为有这个覆盖关系,所以造成有些同学以为正则location 先于普通location 执行的错误理解);但是如果“正则location ”没有能匹配上,那么就用“普通location ”的最大前缀匹配结果。

For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale’s only.

Regular expression may contain captures (0.7.40), which can then be used in other directives.

It is possible to disable regular expression checks after literal string matching by using “^~” prefix. If the most specific match literal location has this prefix: regular expressions aren’t checked.

通常的规则是,匹配完了“普通location ”指令,还需要继续匹配“正则location ”,但是你也可以告诉Nginx :匹配到了“普通location ”后,不再需要继续匹配“正则location ”了,要做到这一点只要在“普通location ”前面加上“^~ ”符号(^ 表示“非”,~ 表示“正则”,字符意思是:不要继续匹配正则)。

By using the “=” prefix we define the exact match between request URI and location. When matched search stops immediately. E.g., if the request “/” occurs frequently, using “location = /” will speed up processing of this request a bit as search will stop after first comparison.

除了上文的“^~ ”可以阻止继续搜索正则location 外,你还可以加“= ”。那么如果“^~ ”和“= ”都能阻止继续搜索正则location 的话,那它们之间有什么区别呢?区别很简单,共同点是它们都能阻止继续搜索正则location ,不同点是“^~ ”依然遵守“最大前缀”匹配规则,然而“= ”不是“最大前缀”,而是必须是严格匹配(exact match )。

这里顺便讲下“location / {} ”和“location = / {} ”的区别,“location / {} ”遵守普通location 的最大前缀匹配,由于任何 URI 都必然以“/ ”根开头,所以对于一个URI ,如果有更specific 的匹配,那自然是选这个更specific 的,如果没有,“/ ”一定能为这个URI 垫背(至少能匹配到“/ ”),也就是说“location / {} ”有点默认配置的味道,其他更specific 的配置能覆盖overwrite 这个默认配置(这也是为什么我们总能看到location / {} 这个配置的一个很重要的原因)。而“location = / {} ”遵守的是“严格精确匹配exact match ”,也就是只能匹配 http://host:port/ 请求,同时会禁止继续搜索正则location 。因此如果我们只想对“GET / ”请求配置作用指令,那么我们可以选“location = / {} ”这样能减少正则location 的搜索,因此效率比“location / {}” 高(注:前提是我们的目的仅仅只想对“GET / ”起作用)。

On exact match with literal location without “=” or “^~” prefixes search is also immediately terminated.

前面我们说了,普通location 匹配完后,还会继续匹配正则location ;但是nginx 允许你阻止这种行为,方法很简单,只需要在普通location 前加“^~ ”或“= ”。但其实还有一种“隐含”的方式来阻止正则location 的搜索,这种隐含的方式就是:当“最大前缀”匹配恰好就是一个“严格精确(exact match )”匹配,照样会停止后面的搜索。原文字面意思是:只要遇到“精确匹配exact match ”,即使普通location 没有带“= ”或“^~ ”前缀,也一样会终止后面的匹配。

先举例解释下,后面例题会用实践告诉大家。假设当前配置是:location /exact/match/test.html { 配置指令块1} ,location /prefix/ { 配置指令块2} 和 location ~ \.html$ { 配置指令块3} ,如果我们请求 GET /prefix/index.html ,则会被匹配到指令块3 ,因为普通location /prefix/ 依据最大匹配原则能匹配当前请求,但是会被后面的正则location 覆盖;当请求GET /exact/match/test.html ,会匹配到指令块1 ,因为这个是普通location 的exact match ,会禁止继续搜索正则location 。

To summarize, the order in which directives are checked is as follows:

1.Directives with the “=” prefix that match the query exactly. If found, searching stops.

2.All remaining directives with conventional strings. If this match used the “^~” prefix, searching stops.

3.Regular expressions, in the order they are defined in the configuration file.

4.If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

这个顺序没必要再过多解释了。但我想用自己的话概括下上面的意思“正则 location 匹配让步普通 location 的严格精确匹配结果;但覆盖普通 location 的最大前缀匹配结果”。

It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match “/images/%20/test”, then you must use “/images/ /test” to determine the location.

在浏览器上显示的URL 一般都会进行URLEncode ,例如“空格”会被编码为%20 ,但是Nginx 的URL 的匹配都是针对URLDecode 之后的。也就是说,如果你要匹配“/images/%20/test ”,你写location 的时候匹配目标应该是:“/images/ /test ”。

Example:

location   = / {

# matches the query / only.

[ configuration A ]

}

location   / {

# matches any query, since all queries begin with /, but regular

# expressions and any longer conventional blocks will be

# matched first.

[ configuration B ]

}

location ^~ /images/ {

# matches any query beginning with /images/ and halts searching,

# so regular expressions will not be checked.

[ configuration C ]

}

location ~* \.(gif|jpg|jpeg)$ {

# matches any request ending in gif, jpg, or jpeg. However, all

# requests to the /images/ directory will be handled by

# Configuration C.

[ configuration D ]

}

上述这4 个location 的配置,没什么好解释的,唯一需要说明的是location / {[configuration B]} ,原文的注释严格来说是错误的,但我相信原文作者是了解规则的,只是文字描述上简化了下,但这个简化容易给读者造成“误解:先检查正则location ,再检查普通location ”。原文:“matches any query, since all queries begin with /, but regular expressions and any longer conventional blocks will be matched first. ”大意是说:“location / {} 能够匹配所有HTTP 请求,因为任何HTTP 请求都必然是以‘/ ’开始的(这半句没有错误)。但是,正则location 和其他任何比‘/ ’更长的普通location (location / {} 是普通location 里面最短的,因此其他任何普通location 都会比它更长,当然location = / {} 和 location ^~ / {} 是一样长的)会优先匹配(matched first )。” 原文作者说“ but regular expressions will be matched first. ”应该只是想说正则 location 会覆盖这里的 location / {} ,但依然是普通 location / {} 先于正则 location 匹配,接着再正则 location 匹配;但其他更长的普通 location ( any longer conventional blocks )的确会先于 location / {} 匹配。

Example requests:

/ -> configuration A

/documents/document.html -> configuration B

/images/1.gif -> configuration C

/documents/1.jpg -> configuration D

Note that you could define these 4 configurations in any order and the results would remain the same.

需要提醒下:这里说“in any order ”和“… remain the same ”是因为上面只有一个正则location 。文章前面已经说了正则location 的匹配是跟编辑顺序有关系的。

While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.

实际上 nginx 的配置文件解析程序是允许 location 嵌套定义的( location / { location /uri/ {} } )。但是我们平时却很少看见这样的配置,那是因为 nginx 官方并不建议大家这么做,因为这样会导致很多意想不到的后果。

The prefix “@” specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page , try_files ).

文章开始说了location 的语法中,可以有“= ”,“^~ ”,“~ ”和“~* ”前缀,或者干脆没有任何前缀,还有“@ ”前缀,但是后面的分析我们始终没有谈到“@ ”前缀。文章最后点内容,介绍了“@”的用途:“@ ”是用来定义“Named Location ”的(你可以理解为独立于“普通location (location using literal strings )”和“正则location (location using regular expressions )”之外的第三种类型),这种“Named Location ”不是用来处理普通的HTTP 请求的,它是专门用来处理“内部重定向(internally redirected )”请求的。注意:这里说的“内部重定向(internally redirected )”或许说成“forward ”会好点,以为内internally redirected 是不需要跟浏览器交互的,纯粹是服务端的一个转发行为。

location 实例练习

Nginx 的语法形式是: location [=|~|~*|^~|@] /uri/ { … } ,意思是可以以“ = ”或“ ~* ”或“ ~ ”或“ ^~ ”或“ @ ”符号为前缀,当然也可以没有前缀(因为 [A] 是表示可选的 A ; A|B 表示 A 和 B 选一个),紧接着是 /uri/ ,再接着是 {…} 指令块,整个意思是对于满足这样条件的 /uri/ 适用指令块 {…} 的指令。

上述各种 location 可分两大类,分别是:“普通 location ”,官方英文说法是 location using   literal strings 和“正则 location ”,英文说法是 location using regular expressions 。其中“普通 location ”是以“ = ”或“ ^~ ”为前缀或者没有任何前缀的 /uri/ ;“正则 location ”是以“ ~ ”或“ ~* ”为前缀的 /uri/ 。

那么,当我们在一个 server 上下文编写了多个 location 的时候, Nginx 对于一个 HTTP 请求,是如何匹配到一个 location 做处理呢?用一句话简单概括 Nginx 的 location 匹配规则是:“正则 location ”让步 “普通 location ”的严格精确匹配结果;但覆盖 “普通 location ”的最大前缀匹配结果。理解这句话,我想通过下面的实例来说明。

#1 先普通 location ,再正则 location

周边不少童鞋告诉我, nginx 是“先匹配正则 location 再匹配普通 location ”,其实这是一个误区, nginx 其实是“先匹配普通 location ,再匹配正则 location ”,但是普通 location 的匹配结果又分两种:一种是“严格精确匹配”,官方英文说法是“ exact match ”;另一种是“最大前缀匹配”,官方英文说法是“ Literal strings match the beginning portion of the query – the most specific match will be used. ”。我们做个实验:

 

例题 1 :假设 nginx 的配置如下

server {

listen       9090;

server_name  localhost;

location / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

附录 nginx 的目录结构是: nginx->html->index.html

上述配置的意思是: location / {… deny all;} 普通 location 以“ / ”开始的 URI 请求(注意任何 HTTP 请求都必然以“ / ”开始,所以“ / ”的意思是所有的请求都能被匹配上),都拒绝访问; location ~\.html$ {allow all;} 正则 location 以 .html 结尾的 URI 请求,都允许访问。

测试结果:

[root@web108 ~]# curl http://localhost:9090/

<html>

<head><title>403 Forbidden</title></head>

<body bgcolor=”white”>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]# curl http://localhost:9090/index.html

<html>

<head>

<title>Welcome to nginx!</title>

</head>

<body bgcolor=”white” text=”black”>

<center><h1>Welcome to nginx!</h1></center>

</body>

</html>

[root@web108 ~]# curl http://localhost:9090/index_notfound.html

<html>

<head><title>404 Not Found</title></head>

<body bgcolor=”white”>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

测试结果如下:

URI 请求 HTTP 响应
curl http://localhost:9090/ 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx!
curl http://localhost:9090/index_notfound.html 404 Not Found

curl http://localhost:9090/ 的结果是“ 403 Forbidden ”,说明被匹配到“ location / {..deny all;} ”了,原因很简单 HTTP 请求 GET / 被“严格精确”匹配到了普通 location / {} ,则会停止搜索正则 location ;

curl http://localhost:9090/index.html 结果是“ Welcome to nginx! ”,说明没有被“ location / {…deny all;} ”匹配,否则会 403 Forbidden ,但 /index.html 的确也是以“ / ”开头的,只不过此时的普通 location / 的匹配结果是“最大前缀”匹配,所以 Nginx 会继续搜索正则 location , location ~ \.html$ 表达了以 .html 结尾的都 allow all; 于是接着就访问到了实际存在的 index.html 页面。

curl http://localhost:9090/index_notfound.html   同样的道理先匹配 location / {} ,但属于“普通 location 的最大前缀匹配”,于是后面被“正则 location ” location ~ \.html$ {} 覆盖了,最终 allow all ; 但的确目录下不存在 index_notfound.html 页面,于是 404 Not Found 。

如果此时我们访问 http://localhost:9090/index.txt 会是什么结果呢?显然是 deny all ;因为先匹配上了 location / {..deny all;} 尽管属于“普通 location ”的最大前缀匹配结果,继续搜索正则 location ,但是 /index.txt 不是以 .html 结尾的,正则 location 失败,最终采纳普通 location 的最大前缀匹配结果,于是 deny all 了。

[root@web108 ~]# curl http://localhost:9090/index.txt

<html>

<head><title>403 Forbidden</title></head>

<body bgcolor=”white”>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

#2 普通 location 的“隐式”严格匹配

例题 2 :我们在例题 1 的基础上增加精确配置

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

测试请求:

[root@web108 ~]# curl http://localhost:9090/exact/match.html

<html>

<head><title>404 Not Found</title></head>

<body bgcolor=”white”>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

结果进一步验证了“普通 location ”的“严格精确”匹配会终止对正则 location 的搜索。这里我们小结下“普通 location ”与“正则 location ”的匹配规则:先匹配普通 location ,再匹配正则 location ,但是如果普通 location 的匹配结果恰好是“严格精确( exact match )”的,则 nginx 不再尝试后面的正则 location ;如果普通 location 的匹配结果是“最大前缀”,则正则 location 的匹配覆盖普通 location 的匹配。也就是前面说的“正则 location 让步普通 location 的严格精确匹配结果,但覆盖普通 location 的最大前缀匹配结果”。

#3 普通 location 的“显式”严格匹配和“ ^~ 前缀

上面我们演示的普通 location 都是不加任何前缀的,其实普通 location 也可以加前缀:“ ^~ ”和“ = ”。其中“ ^~ ”的意思是“非正则,不需要继续正则匹配”,也就是通常我们的普通 location ,还会继续搜索正则 location (恰好严格精确匹配除外),但是 nginx 很人性化允许配置人员告诉 nginx 某条普通 location ,无论最大前缀匹配,还是严格精确匹配都终止继续搜索正则 location ;而“ = ”则表达的是普通 location 不允许“最大前缀”匹配结果,必须严格等于,严格精确匹配。

例题 3 :“ ^~ ”前缀的使用

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location ^~ / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

把例题 2 中的 location / {} 修改成 location ^~ / {} ,再看看测试结果:

URI 请求 修改前 修改后
curl http://localhost:9090/ 403 Forbidden 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx! 403 Forbidden
curl http://localhost:9090/index_notfound.html 404 Not Found 403 Forbidden
curl http://localhost:9090/exact/match.html 404 Not Found 404 Not Found

除了 GET /exact/match.html 是 404 Not Found ,其余都是 403 Forbidden ,原因很简单所有请求都是以“ / ”开头,所以所有请求都能匹配上“ / ”普通 location ,但普通 location 的匹配原则是“最大前缀”,所以只有 /exact/match.html 匹配到 location /exact/match.html {allow all;} ,其余都 location ^~ / {deny all;} 并终止正则搜索。

例题 4 :“ = ”前缀的使用

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location = / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

例题 4 相对例题 2 把 location / {} 修改成了 location = / {} ,再次测试结果:

URI 请求 修改前 修改后
curl http://localhost:9090/ 403 Forbidden 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx! Welcome to nginx!
curl http://localhost:9090/index_notfound.html 404 Not Found 404 Not Found
curl http://localhost:9090/exact/match.html 404 Not Found 404 Not Found
curl http://localhost:9090/test.jsp 403 Forbidden 404 Not Found

最能说明问题的测试是 GET /test.jsp ,实际上 /test.jsp 没有匹配正则 location ( location ~\.html$ ),也没有匹配 location = / {} ,如果按照 location / {} 的话,会“最大前缀”匹配到普通 location / {} ,结果是 deny all 。

#4 正则 location 与编辑顺序

location 的指令与编辑顺序无关,这句话不全对。对于普通 location 指令,匹配规则是:最大前缀匹配(与顺序无关),如果恰好是严格精确匹配结果或者加有前缀“ ^~ ”或“ = ”(符号“ = ”只能严格匹配,不能前缀匹配),则停止搜索正则 location ;但对于正则 location 的匹配规则是:按编辑顺序逐个匹配(与顺序有关),只要匹配上,就立即停止后面的搜索。

配置 3.1

server {

listen       9090;

server_name  localhost;

location ~ \.html$ {

allow all;

}

location ~ ^/prefix/.*\.html$ {

deny all;

}

}

配置 3.2

server {

listen       9090;

server_name  localhost;

location ~ ^/prefix/.*\.html$ {

deny all;

}

location ~ \.html$ {

allow all;

}

}

测试结果:

URI 请求 配置 3.1 配置 3.2
curl http://localhost:9090/regextest.html 404 Not Found 404 Not Found
curl http://localhost:9090/prefix/regextest.html 404 Not Found 403 Forbidden

解释:

Location ~ ^/prefix/.*\.html$ {deny all;} 表示正则 location 对于以 /prefix/ 开头, .html 结尾的所有 URI 请求,都拒绝访问;   location ~\.html${allow all;} 表示正则 location 对于以 .html 结尾的 URI 请求,都允许访问。 实际上, prefix 的是 ~\.html$ 的子集。

在“配置 3.1 ”下,两个请求都匹配上 location ~\.html$ {allow all;} ,并且停止后面的搜索,于是都允许访问, 404 Not Found ;在“配置 3.2 ”下, /regextest.html 无法匹配 prefix ,于是继续搜索 ~\.html$ ,允许访问,于是 404 Not Found ;然而 /prefix/regextest.html 匹配到 prefix ,于是 deny all , 403 Forbidden 。

配置 3.3

server {

listen       9090;

server_name  localhost;

location  /prefix/ {

deny all;

}

location  /prefix/mid/ {

allow all;

}

}

配置 3.4

server {

listen       9090;

server_name  localhost;

location  /prefix/mid/ {

allow all;

}

location  /prefix/ {

deny all;

}

}

测试结果:

URI 请求 配置 3.1 配置 3.2
curl http://localhost:9090/prefix/t.html 403 Forbidden 403 Forbidden
curl http://localhost:9090/prefix/mid/t.html 404 Not Found 404 Not Found

测试结果表明:普通 location 的匹配规则是“最大前缀”匹配,而且与编辑顺序无关。

#5 “@ 前缀 Named Location 使用

REFER:  http://wiki.nginx.org/HttpCoreModule#error_page

假设配置如下:

server {

listen       9090;

server_name  localhost;

location  / {

root   html;

index  index.html index.htm;

allow all;

}

#error_page 404 http://www.baidu.com # 直接这样是不允许的

error_page 404 = @fallback;

location @fallback {

proxy_pass http://www.baidu.com;

}

}

上述配置文件的意思是:如果请求的 URI 存在,则本 nginx 返回对应的页面;如果不存在,则把请求代理到 baidu.com 上去做个弥补(注: nginx 当发现 URI 对应的页面不存在, HTTP_StatusCode 会是 404 ,此时 error_page 404 指令能捕获它)。

测试一:

[root@web108 ~]# curl http://localhost:9090/nofound.html -i

HTTP/1.1 302 Found

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:17:21 GMT

Content-Type: text/html; charset=iso-8859-1

Location: http://localhost:9090/search/error.html

Connection: keep-alive

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:17:21 GMT

Content-Length: 222

 

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html“>here</a>.</p>

</body></html>

[root@web108 ~]#

当我们 GET /nofound.html 发送给本 nginx , nginx 找不到对应的页面,于是 error_page 404 = @fallback ,请求被代理到 http://www.baidu.com ,于是 nginx 给 http://www.baidu.com 发送了 GET /nofound.html ,但 /nofound.html 页面在百度也不存在,百度 302 跳转到错误页。

直接访问 http://www.baidu.com/nofound.html 结果:

[root@web108 ~]# curl http://www.baidu.com/nofound.html -i

HTTP/1.1 302 Found

Date: Sat, 06 Aug 2011 08:20:05 GMT

Server: Apache

Location: http://www.baidu.com/search/error.html

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:20:05 GMT

Content-Length: 222

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

 

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html“>here</a>.</p>

</body></html>

[root@web108 ~]#

 

测试二:访问一个 nginx 不存在,但 baidu 存在的页面

[root@web108 ~]# curl http://www.baidu.com/duty/ -i

HTTP/1.1 200 OK

Date: Sat, 06 Aug 2011 08:21:56 GMT

Server: Apache

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=5C5D2B2FD083737A0C88CA7075A6601A:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=5C5D2B2FD083737A2337F78F909CCB90:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340”

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:21:56 GMT

Vary: Accept-Encoding,User-Agent

Connection: Keep-Alive

Content-Type: text/html

 

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

http://www.w3.org/TR/html4/loose.dtd“>

。。。。

</body>

</html>

显示,的确百度这个页面是存在的。

[root@web108 ~]# curl http://localhost:9090/duty/ -i

HTTP/1.1 200 OK

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:23:23 GMT

Content-Type: text/html

Connection: keep-alive

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=8FEF0A3A2C31D277DCB4CC5F80B7F457:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=8FEF0A3A2C31D277B1F87691AFFD7440:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340”

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:23:23 GMT

Vary: Accept-Encoding,User-Agent

 

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

http://www.w3.org/TR/html4/loose.dtd“>

<html>

。。。

</body>

</html>

当 curl http://localhost:9090/duty/ -i 时, nginx 没找到对应的页面,于是 error_page = @fallback ,把请求代理到 baidu.com 。注意这里的 error_page = @fallback 不是靠重定向实现的,而是所说的“ internally redirected ( forward )”。

数据库关系模式的理解

第一范式(1NF):

数据库系统概论引用:

  1. 列是同质的(Homogeneous),即每一列中的分量是同一类型的数据,来自同一个域.
  2. 不同的列可出自同一个域,称其中的每一列为一个属性,不同的属性要给予不同的属性名.
  3. 列的顺序无所谓,即列的次序可以任意交换.
  4. 任意两个元组不能完全相同.
  5. 行的顺序无所谓,即行的次序可以任意交换.
  6. 分量必须取原子值,即每一个分量都必须是不可分的数据项.

所谓第一范式(1NF)是指在关系模型中,对域添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。
说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的设计基本要求,一般设计中都必须满足第一范式(1NF)。不过有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。换句话说,是否必须满足1NF的最低要求,主要依赖于所使用的关系模型。

第二范式(2NF):

数据库系统概论引用:
若R<U,F>∈1NF,并且每一个非主属性都完全函数依赖于码,则R<U,F>∈2NF。

在1NF的基础上,非码属性必须完全依赖于码[在1NF基础上消除非主属性对主码的部分函数依赖]
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组,作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分,该身份证号码即为候选键,任何一个候选键都可以被选作主键。在找不到候选键时,可额外增加属性以实现区分,如果在员工关系中,没有对其身份证号进行存储,而姓名可能会在数据库运行的某个时间重复,无法区分出实体时,设计辟如ID等不重复的编号以实现区分,被添加的编号或ID选作主键。(该主键的添加是在ER设计时添加,不是建库时随意添加)
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式(3NF):

数据库系统概论引用:
传递依赖:在R<U,F>中,如果X → Y,(Y ⊈ X),Y !→ X,Y → Z,则称Z对X传递函数依赖.

3NF:关系模式R<U,F>中若不存在这样的码X,属性组Y及非主属性Z(Z⊈Y), 使得X → Y,Y → Z成立,Y !→ X,则称R<U,F>∈3NF。

简单的说,就是没有传递的第二范式。

第三范式(3NF)是第二范式(2NF)的一个子集,即满足第三范式(3NF)必须满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性,也就是在满足2NF的基础上,任何非主属性不得传递依赖于主属性。

数据库系统概论引用:
设关系模式R<U,F>∈1NF,若X → Y且Y ⊈ X时X必含码,则R<U,F>∈BCNF。

在1NF基础上,任何非主属性不能对主键子集依赖[在3NF基础上消除对主码子集的依赖]
巴斯-科德范式(BCNF)是第三范式(3NF)的一个子集,即满足巴斯-科德范式(BCNF)必须满足第三范式(3NF)。通常情况下,巴斯-科德范式被认为没有新的设计规范加入,只是对第二范式与第三范式中设计规范要求更强,因而被认为是修正第三范式,也就是说,它事实上是对第三范式的修正,使数据库冗余度更小。这也是BCNF不被称为第四范式的原因。某些书上,根据范式要求的递增性将其称之为第四范式是不规范,也是更让人不容易理解的地方。而真正的第四范式,则是在设计规范中添加了对多值及依赖的要求。
对于BCNF,在主码的任何一个真子集都不能决定于主属性。关系中U主码,若U中的任何一个真子集X都不能决定于主属性Y,则该设计规范属性BCNF。例如:在关系R中,U为主码,A属性是主码中的一个属性,若存在A->Y,Y为主属性,则该关系不属于BCNF。
一般关系型数据库设计中,达到BCNF就可以了!

让IE浏览器打开JSON文件直接显示

为了测试更方便,一般我使用 Web API 都会设置让 Web API 返回 Json 格式。在IE浏览器中,当伙同在地址输入 URL 后 IE 浏览器会弹出是否需要下载的提示。
实际上 IE 弹出下载提示也没有什么不好的,但是有时候想要迫不及待的看到Json返回的结果时,又需要反复的下载再打开查看,这个行为就显得让人讨厌了。如果能够像 Chrome 或 Firefox 可直接看结果就好了。<>

解决办法也非常简单,需要我们在操作系统的注册表中添加关于 JSON 的 MIME 类型支持,你可以将以下内容编辑成扩展名为 .reg 的文件(文件名随意),然后双击执行将该文件导入注册表:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOTMIMEDatabaseContent Typeapplication/json]

"CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}"

"Encoding"=dword:00080000

[HKEY_CLASSES_ROOTMIMEDatabaseContent Typetext/json]

"CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}"

"encoding"=dword:00080000

其原理是修改注册表,将 application/json、text/json 两种 Content-Type 开启设置调成与 GIF/PNG/HTML 一致,改为直接用浏览器打开查看。

导入上面的注册表文件以后,再使用IE开启就可以不需要下载即可显示 json 了。

Nginx 禁止IP访问

需求:
在Nginx上设置禁止通过IP访问服务器,只能通过域名访问。

注意:默认情况下,nginx中的虚拟主机是允许用户通过IP访问,或者通过未设置的域名访问的。

关键一点是在server的设置里添加一行:

listen 80 default_server;

后面的default_server参数表示这个是默认虚拟主机。此设置很有用。
假如有人通过ip或者未知域名访问你的网站的时候,你希望禁止显示任何有效内容,可以给他返回500。
目前国内很多机房都要求网站主关闭空主机头,防止未备案的域名指向过来造成麻烦,则可以这样设置:

 
server {
listen 80 default_server;
return 500;
}

也可以把这些流量收集起来,导入到自己的网站,只要做以下跳转设置就可以:

server {
listen 80 default_server;
rewrite ^(.*) http://www.mywebsite.com permanent;
}

按照如上设置后,确实不能通过IP访问服务器了,但是在应该用中出现当server_name后跟多个域名时,其中一个域名怎么都无法访问。设置如下:

 
server
{
listen 80;
server_name www.mywebsite.com mywebsite.com;
}

没更改之前,通过server_name中的www.mywebsite.com mywebsite.com均可访问服务器,加入禁止IP访问的设置后,通过mywebsite.com无法访问服务器了,www.mywebsite.com mywebsite.com可以访问

用 nginx -t 检测配置文件会提示warning:
[warn]: conflicting server name “mywebsite.com” on 0.0.0.0:80, ignored
the configuration file /usr/local/webserver/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/webserver/nginx/conf/nginx.conf test is successful

最后,通过在listen 80 default;后再加server_name _;进行解决,形式如下:

 
server
{
listen 80 default_server;
server_name _;
return 500;
}

或者
server {
listen 80 dufault_server;
server_name _;
rewrite ^(.*) http://www.mywebsite.com permanent;
}

这样,通过mywebsite.com就能访问服务器了,问题解决了,但具体原因还是不清楚。

Events模块

events模块中包含nginx中所有处理连接的设置。

events { 
worker_connections 2048; 
multi_accept on; 
use epoll; 
} 
Syntax:	worker_connections number;
Default:	
worker_connections 512;
Context:	events

Sets the maximum number of simultaneous connections that can be opened by a worker process.
It should be kept in mind that this number includes all connections (e.g. connections with proxied servers, among others), not only connections with clients. Another consideration is that the actual number of simultaneous connections cannot exceed the current limit on the maximum number of open files, which can be changed by worker_rlimit_nofile.

设置可由一个worker进程同时打开的最大连接数。如果设置了上面提到的worker_rlimit_nofile,我们可以将这个值设得很高。
理论上,每台nginx服务器的最大连接数为worker_processes * worker_connections。
记住,最大客户数也由系统的可用socket连接数限制(~ 64K),所以设置不切实际的高没什么好处。

Syntax:	multi_accept on | off;
Default:	
multi_accept off;
Context:	events

If multi_accept is disabled, a worker process will accept one new connection at a time. Otherwise, a worker process will accept all new connections at a time.

The directive is ignored if kqueue connection processing method is used, because it reports the number of new connections waiting to be accepted.

告诉nginx收到一个新连接通知后接受尽可能多的连接。

Syntax:	use method;
Default:	—
Context:	events

Specifies the connection processing method to use. There is normally no need to specify it explicitly, because nginx will by default use the most efficient method.

设置用于复用客户端线程的轮询方法。如果你使用Linux 2.6+,你应该使用epoll。如果你使用*BSD,你应该使用kqueue。
(值得注意的是如果你不知道Nginx该使用哪种轮询方法的话,它会选择一个最适合你操作系统的)

worker_processes

worker_processes
定义了nginx对外提供web服务时的worker进程数。最优值取决于许多因素,包括(但不限于)CPU核的数量、存储数据的硬盘数量及负载模式。

不能确定的时候,将其设置为可用的CPU内核数将是一个好的开始(设置为“auto”将尝试自动检测它)。亦可设置为其2倍,以优化性能。

查看CPU内核数:

cat /proc/cpuinfo | grep processor

worker_rlimit_nofile

  1. worker_rlimit_nofile

更改worker进程的最大打开文件数限制。如果没设置的话,这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件,所以把这个值设高,这样nginx就不会有“too many open files”问题了。

查看系统的最大文件数:

ulimit -a
ulimit -n

更改系统最大文件数设置:

ulimit -v unlimited
cat &gt;&gt;/etc/security/limits.conf&lt;&lt;eof
* soft nproc 65535
* hard nproc 65535
* soft nofile 65535
* hard nofile 65535
eof

Nginx的accept_mutex配置

Syntax: accept_mutex on | off;
Default:
accept_mutex on;
Context: events

Syntax: accept_mutex_delay time;
Default:
accept_mutex_delay 500ms;
Context: events

Nginx的accept_mutex配置

通常多数人不会注意Nginx的accept_mutex配置,不过实际上它对系统的吞吐量有一定的影响,今天生物钟紊乱睡不着觉,索性闲扯一下Nginx的accept_mutex配置。

让我们看看accept_mutex的意义:当一个新连接到达时,如果激活了accept_mutex,那么多个Worker将以串行方式来处理,其中有一个Worker会被唤醒,其他的Worker继续保持休眠状态;如果没有激活accept_mutex,那么所有的Worker都会被唤醒,不过只有一个Worker能获取新连接,其它的Worker会重新进入休眠状态,这就是「惊群问题」。

Nginx缺省激活了accept_mutex,也就是说不会有惊群问题,但真的有那么严重么?实际上Nginx作者Igor Sysoev曾经给过相关的解释:

OS may wake all processes waiting on accept() and select(), this is called thundering herd problem. This is a problem if you have a lot of workers as in Apache (hundreds and more), but this insensible if you have just several workers as nginx usually has. Therefore turning accept_mutex off is as scheduling incoming connection by OS via select/kqueue/epoll/etc (but not accept()).

简单点说:Apache动辄就会启动成百上千的进程,如果发生惊群问题的话,影响相对较大;但是对Nginx而言,一般来说,worker_processes会设置成CPU个数,所以最多也就几十个,即便发生惊群问题的话,影响相对也较小。

另:高版本的Linux中,accept不存在惊群问题,不过epoll_wait等操作还有。

假设你养了一百只小鸡,现在你有一粒粮食,那么有两种喂食方法:

  • 你把这粒粮食直接扔到小鸡中间,一百只小鸡一起上来抢,最终只有一只小鸡能得手,其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
  • 你主动抓一只小鸡过来,把这粒粮食塞到它嘴里,其它九十九只小鸡对此浑然不知,该睡觉睡觉。这就相当于激活了accept_mutex。可以看到此场景下,激活accept_mutex相对更好一些,让我们修改一下问题的场景,我不再只有一粒粮食,而是一盆粮食,怎么办?

此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了,一盆粮食不知何年何月才能喂完,大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间,让它们自己去抢,虽然这可能会造成一定程度的混乱,但是整体的效率无疑大大增强了。

Nginx缺省激活了accept_mutex,是一种保守的选择。如果关闭了它,可能会引起一定程度的惊群问题,表现为上下文切换增多(sar -w)或者负载上升,但是如果你的网站访问量比较大,为了系统的吞吐量,我还是建议大家关闭它。

来源:http://huoding.com/2013/08/24/281

MySQL 用户与授权管理详解

一、前言
做为Mysql数据库管理员管理用户账户,是一件很重要的事,指出哪个用户可以连接服务器,从哪里连接,连接后能做什么。Mysql从3.22.11开始引入两个语句来做这件事,GRANT语句创建Mysql用户并指定其权限,而REVOKE语句删除权限。CREATE和REVOKE语句影响4个表,
user 能连接服务器的用户以及他们拥有的任何全局权限
db 数据库级权限
tables_priv 表级权限
columns_priv 列级权限
还有第5个授权表host,但它不受GRANT和REVOKE的影响
当你对一个用户发出一条GRANT语句时,在user表中为该用户创建一条记录。如果语句指定任何全局权限(管理权限或适用于所有数据库的权限),这些也记录在user表中。如果你指定数据库、表和列级权限,他们被分别记录在db、tables_priv和columns_priv表中。

二、创建用户并授权
1.GRANT 语句的用法

mysql> help grant 
Name: 'GRANT'  
Description:  
Syntax:  
GRANT  
    priv_type [(column_list)]  
      [, priv_type [(column_list)]] ...  
    ON [object_type] priv_level  
    TO user_specification [, user_specification] ...  
    [REQUIRE {NONE | ssl_option [[AND] ssl_option] ...}]  
    [WITH with_option ...]

GRANT语句的语法看上去像这样,

GRANT privileges [columns] ON what TO user IDENTIFIED BY "password" WITH GRANT OPTION;

2.权限分类 (privileges)
第一组:指定符适用于数据库、表和列
ALTER 修改表和索引
CREATE 创建数据库和表
DELETE 删除表中已有的记录
DROP 删除数据库和表
INDEX 创建或抛弃索引
INSERT 向表中插入新行
REFERENCE 未用
SELECT 检索表中的记录
UPDATE 修改现存表记录
第二组:指定数据库数管理权限
FILE 读或写服务器上的文件
PROCESS 查看服务器中执行的线程信息或杀死线程
RELOAD 重载授权表或清空日志、主机缓存或表缓存
SHUTDOWN 关闭服务器
第三组权限特殊:ALL意味着“所有权限”,UASGE意味着无权限,即创建用户,但不授予权限
ALL 所有;ALL PRIVILEGES“所有权限”
USAGE 特殊的“无权限”权限
3.columns
权限运用的列,它是可选的,并且你只能设置列特定的权限。如果命令有多于一个列,应该用逗号分开它们。
4.what
权限运用的级别。权限可以是全局的(适用于所有数据库和所有表)、特定数据库(适用于一个数据库中的所有表)或特定表的。可以通过指定一个columns字句是权限是列特定的。
5.user
权限授予的用户,它由一个用户名和主机名组成。在MySQL中,你不仅指定谁能连接,还有从哪里连接。这允许你让两个同名用户从不同地方连接。MySQL让你区分他们,并彼此独立地赋予权限。
MySQL中的一个用户名就是你连接服务器时指定的用户名,该名字不必与你的Unix登录名或Windows名联系起来。缺省地,如果你不明确指定一个名字,客户程序将使用你的登录名作为MySQL用户名。这只是一个约定。你可以在授权表中将该名字改为nobody,然后以nobody连接执行需要超级用户权限的操作。
6.password
赋予用户的口令,它是可选的。如果你对新用户没有指定IDENTIFIED BY子句,该用户不赋给口令(不安全)。对现有用户,任何你指定的口令将代替老口令。如果你不指定口令,老口令保持不变,当你用IDENTIFIED BY时,口令字符串用改用口令的字面含义,GRANT将为你编码口令,不要象你用SET PASSWORD 那样使用password()函数。
7.WITH GRANT OPTION子句是可选的。如果你包含它,用户可以授予权限通过GRANT语句授权给其它用户。你可以用该子句给与其它用户授权的能力。
注:用户名、口令、数据库和表名在授权表记录中是大小写敏感的,而主机名和列名不是。

三、GRANT语句的种类
一般地,你可以通过询问几个简单的问题来识别GRANT语句的种类:
谁能连接,从那儿连接?
用户应该有什么级别的权限,他们适用于什么?
用户应该允许管理权限吗?
1.谁能连接,从那儿连接?
(1).你可以允许一个用户从特定的或一系列主机连接。

GRANT ALL ON db.* TO free@localhost  IDENTIFIED BY "123456";

说明:db.*意思是“db数据库的所有表
(2).你可能有一个经常外出并需要能从任何主机连接的用户free。在这种情况下,你可以允许他无论从哪里连接:

GRANT ALL ON db.* TO free@% IDENTIFIED BY "123456";

说明:“%”字符起通配符作用,与LIKE模式匹配的含义相同。在上述语句中,它意味着“任何主机”。所以free和free@%等价。这是建立用户最简单的方法,但也是最不安全的。
(3).你可以允许一个用户从一个受限的主机集合访问。例如,要允许mary从free.net域的任何主机连接,用一个%.free.net主机指定符:

GRANT ALL ON db.* TO mary@%.free.net IDENTIFIED BY "123456";

(4).如果你喜欢,用户标识符的主机部分可以用IP地址而不是一个主机名来给定。你可以指定一个IP地址或一个包含模式字符的地址,而且,从MySQL 3.23,你还可以指定具有指出用于网络号的位数的网络掩码的IP号:

GRANT ALL ON db.* TO free@192.168.12.10  IDENTIFIED BY "123456";
GRANT ALL ON db.* TO free@192.168.12.% IDENTIFIED BY "123456";
GRANT ALL ON db.* TO free@192.168.12.0/24  IDENTIFIED BY "123456";

说明:第一个例子指出用户能从其连接的特定主机,第二个指定对于C类子网192.168.12的IP模式,而第三条语句中,192.168.12.0/24指定一个24位网络号并匹配具有192.168.12头24位的IP地址。
(5).如果你指定的用户值报错,你可能需要使用引号(只将用户名和主机名部分分开加引号)。

GRANT ALL ON db.* TO "free"@"test.free.net"  IDENTIFIED BY "123456";

2.用户应该有什么级别的权限和它们应该适用于什么?
(1).你可以授权不同级别的权限,全局权限是最强大的,因为它们适用于任何数据库。要使free成为可做任何事情的超级用户,包括能授权给其它用户,发出下列语句:

GRANT ALL ON *.* TO free@localhost IDENTIFIED BY "123456" WITH GRANT OPTION;

说明:ON子句中的*.*意味着“所有数据库、所有表”。从安全考虑,我们指定free只能从本地连接。限制一个超级用户可以连接的主机通常是明智的,因为它限制了试图破解口令的主机。
有些权限(FILE、PROCESS、RELOAD和SHUTDOWN)是管理权限并且只能用”ON *.*”全局权限指定符授权。如果你愿意,你可以授权这些权限,而不授权数据库权限。例如,下列语句设置一个flush用户,他只能发出flush语句。这可能在你需要执行诸如清空日志等的管理脚本中会有用:

GRANT RELOAD ON *.* TO flushl@localhost IDENTIFIED BY "123456";

一般地,你想授权管理权限,吝啬点,因为拥有它们的用户可以影响你的服务器的操作。
(2).数据库级权限适用于一个特定数据库中的所有表,它们可通过使用ON db_name.*子句授予:

GRANT ALL ON db TO free@test.free.net INDETIFIED BY "123456";
GRANT SELECT ON db TO free@% INDETIFIED BY "123456";

说明:第一条语句向free授权db数据库中所有表的权限,第二条创建一个严格限制访问的用户free(只读用户),只能访问db数据库中的所有表,但只有读取,即用户只能发出SELECT语句。你可以列出一系列同时授予的各个权限。例如,如果你想让用户能读取并能修改现有数据库的内容,但不能创建新表或删除表,如下授予这些权限:

GRANT SELECT,INSERT,DELETE,UPDATE ON db TO free@test.net INDETIFIED BY "123456";

(3).对于更精致的访问控制,你可以在各个表上授权,或甚至在表的每个列上。当你想向用户隐藏一个表的部分时,或你想让一个用户只能修改特定的列时,列特定权限非常有用。如:

GRANT SELECT ON db.member TO free@localhost INDETIFIED BY "123456";
GRANT UPDATE (expiration) ON db. member TO free@localhost;

说明:第一条语句授予对整个member表的读权限并设置了一个口令,第二条语句增加了UPDATE权限,当只对expiration列。没必要再指定口令,因为第一条语句已经指定了。
(4).如果你想对多个列授予权限,指定一个用逗号分开的列表。例如,对free用户增加member表的地址字段的UPDATE权限,使用如下语句,新权限将加到用户已有的权限中:

GRANT UPDATE (street,city,state,zip) ON db TO free@localhost ;

说明:通常,你不想授予任何比用户确实需要的权限宽的权限。然而,当你想让用户能创建一个临时表以保存中间结果,但你又不想让他们在一个包含他们不应修改内容的数据库中这样做时,发生了要授予在一个数据库上的相对宽松的权限。你可以通过建立一个分开的数据库(如tmp)并授予开数据库上的所有权限来进行。例如,如果你想让来自test.net域中主机的任何用户使用tmp数据库,你可以发出这样的GRANT语句:

GRANT ALL ON tmp.* TO ""@test.net;

在你做完之后,用户可以创建并用tmp.tb_name形式引用tmp中的表(在用户指定符中的””创建一个匿名用户,任何用户均匹配空白用户名)。
3 用户应该被允许管理权限吗?
你可以允许一个数据库的拥有者通过授予数据库上的所有拥有者权限来控制数据库的访问,在授权时,指定WITH GRANT OPTION。例如:如果你想让free能从big.free.com域的任何主机连接并具有sales数据库中所有表的管理员权限,你可以用如下GRANT语句:

GRANT ALL ON sales.* TO free@%.big.free.com INDETIFIED BY "123456" WITH GRANT OPTION;

在效果上WITH GRANT OPTION子句允许你把访问授权的权利授予另一个用户。要注意,拥有GRANT权限的两个用户可以彼此授权。如果你只给予了第一个用户SELECT权限,而另一个用户有GRANT加上SELECT权限,那么第二个用户可以是第一个用户更“强大”。
四、撤权并删除用户
要取消一个用户的权限,使用REVOKE语句。REVOKE的语法非常类似于GRANT语句,除了TO用FROM取代并且没有INDETIFED BY和WITH GRANT OPTION子句:

mysql> help REVOKE 
Name: 'REVOKE'  
Description:  
Syntax:  
REVOKE  
    priv_type [(column_list)]  
      [, priv_type [(column_list)]] ...  
    ON [object_type] priv_level  
    FROM user [, user] ...

REVOKE 语句的语法看上去像这样,

REVOKE privileges (columns) ON what FROM user;  

1.user部分必须匹配原来GRANT语句的你想撤权的用户的user部分。
2.privileges部分不需匹配,你可以用GRANT语句授权,然后用REVOKE语句只撤消部分权限。
3.REVOKE语句只删除权限,而不删除用户。即使你撤销了所有权限,在user表中的用户记录依然保留,这意味着用户仍然可以连接服务器。要完全删除一个用户,你必须用一条DELETE语句明确从user表中删除用户记录,具体操作如下:

mysql>DELETE FROM user WHERE User="user_name" and Host="host_name";
mysql>FLUSH PRIVILEGES;

DELETE语句删除用户记录,而FLUSH语句告诉服务器重载授权表。(当你使用GRANT和REVOKE语句时,表自动重载,而你直接修改授权表时不是)。

LOG!LOG!LOG!重要的事要说3遍!

前两天刚自己查pptpd的debug log找问题,今天竟然一再犯同样的错误,不可原谅么…
nginx.org上边就给出了rewrite选项的配置,我竟然视而不见,在傻傻的google,盲目的改rewrite,systemctl restart nginx,去QQ群找大神,what the fuck!能再2一点不.
还好,在我最暴躁的时候,还是QQ里边的大神”杰出青年@LFS/Gentoo/Arch超级群”点醒了我,”打开 rewrite log,自己调试”,感谢!

一翻对比下来,发现rewrite规则并没有出错,出错的一直都是自己,what the fuck!虽然一切都看起来很正常,但yii还是死活不能正常的跑起来,DAMN IT!

正一筹莫展的时候,突然想起了centos7有个命令”getenforce”,好吧,在鼓下”setenforce 0″的时候,终于一切正常了…

真的一切正常了吗?

记录一下rewrite规则…

        location /api/
        {
            if (!-e $request_filename){
            rewrite ^(.+)$ /api/index.php?q=$1 last;
            #rewrite ^(.+)$ /api/index.php?$1 last;
            #rewrite ^(.+)$ /api/index.php?$1& last;    # all worked
            }
         }