网站首页 > 物联资讯 > 技术分享

Nginx 配置指令的执行顺序(十一)

2016-09-28 00:00:00 广州睿丰德信息科技有限公司 阅读
睿丰德科技 专注RFID识别技术和条码识别技术与管理软件的集成项目。质量追溯系统、MES系统、金蝶与条码系统对接、用友与条码系统对接

紧跟在 post-access 阶段之后的是 try-files 阶段。这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序。由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下。

 

    try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对象(文件或者目录),然后检查这些对象是否存在。一旦 Nginx 发现某个文件系统对象存在,就会在 try-files 阶段把当前请求的 URI 改写为该对象所对应的参数 URI(但不会包含末尾的斜杠字符,也不会发生 “内部跳转”)。如果前 N-1 个参数所对应的文件系统对象都不存在,try-files 阶段就会立即发起“内部跳转”到最后一个参数(即第 N 个参数)所指定的 URI.

 

    前面在 (六) 和 (七) 中已经看到静态资源服务模块会把当前请求的 URI 映射到文件系统,通过 root配置指令所指定的“文档根目录”进行映射。例如,当“文档根目录”是 /var/www/ 的时候,请求 URI/foo/bar 会被映射为文件 /var/www/foo/bar,而请求 URI /foo/baz/ 则会被映射为目录 /var/www/foo/baz/. 注意这里是如何通过 URI 末尾的斜杠字符是否存在来区分“目录”和“文件”的。我们正在讨论的 try_files配置指令使用同样的规则来完成其各个参数 URI 到文件系统对象的映射。

 

    不妨来看下面这个例子:

    root /var/www/;
 
    location /test {
        try_files /foo /bar/ /baz;
        echo "uri: $uri";
    }
 
    location /foo {
        echo foo;
    }
 
    location /bar/ {
        echo bar;
    }
 
    location /baz {
        echo baz;
    }

这里通过 root 指令把“文档根目录”配置为 /var/www/,如果你系统中的 /var/www/ 路径下存放有重要数据,则可以把它替换为其他任意路径,但此路径对运行 Nginx worker 进程的系统帐号至少有可读权限。我们在location /test 中使用了 try_files 配置指令,并提供了三个参数,/foo/bar/ 和 /baz. 根据前面对try_files 指令的介绍,我们可以知道,它会在 try-files 阶段依次检查前两个参数 /foo 和 /bar/ 所对应的文件系统对象是否存在。

 

    不妨先来做一组实验。假设现在 /var/www/ 路径下是空的,则第一个参数 /foo 映射成的文件/var/www/foo 是不存在的;同样,对于第二个参数 /bar/ 所映射成的目录 /var/www/bar/ 也是不存在的。于是此时 Nginx 会在 try-files 阶段发起到最后一个参数所指定的 URI(即 /baz)的“内部跳转”。实际的请求结果证实了这一点:

    $ curl localhost:8080/test
    baz

显然,该请求最终和 location /baz 绑定在一起,执行了输出 baz 字符串的工作。上例中定义的 location /foo 和 location /bar/ 完全不会参与这里的运行过程,因为对于 try_files 的前 N-1 个参数,Nginx 只会检查文件系统,而不会去执行 URI 与 location 之间的匹配。

 

    对于上面这个请求,Nginx 会产生类似下面这样的“调试日志”:

    $ grep trying logs/error.log
    [debug] 3869#0: *1 trying to use file: "/foo" "/var/www/foo"
    [debug] 3869#0: *1 trying to use dir: "/bar" "/var/www/bar"
    [debug] 3869#0: *1 trying to use file: "/baz" "/var/www/baz"

通过这些信息可以清楚地看到 try-files 阶段发生的事情:Nginx 依次检查了文件 /var/www/foo 和目录/var/www/bar,末了又处理了最后一个参数 /baz. 这里最后一条“调试信息”容易产生误解,会让人误以为 Nginx 也把最后一个参数 /baz 给映射成了文件系统对象进行检查,事实并非如此。当 try_files 指令处理到它的最后一个参数时,总是直接执行“内部跳转”,而不论其对应的文件系统对象是否存在。

 

    接下来再做一组实验:在 /var/www/ 下创建一个名为 foo 的文件,其内容为 hello world(注意你需要有/var/www/ 目录下的写权限):

    $ echo 'hello world' > /var/www/foo

然后再请求 /test 接口:

    $ curl localhost:8080/test
    uri: /foo

这里发生了什么?我们来看,try_files 指令的第一个参数 /foo 可以映射为文件 /var/www/foo,而 Nginx 在try-files 阶段发现此文件确实存在,于是立即把当前请求的 URI 改写为这个参数的值,即 /foo,并且不再继续检查后面的参数,而直接运行后面的请求处理阶段。

 

    上面这个请求在 try-files 阶段所产生的“调试日志”如下:

    $ grep trying logs/error.log
    [debug] 4132#0: *1 trying to use file: "/foo" "/var/www/foo"

显然,在 try-files 阶段,Nginx 确实只检查和处理了 /foo 这一个参数,而后面的参数都被“短路”掉了。

 

    类似地,假设我们删除刚才创建的 /var/www/foo 文件,而在 /var/www/ 下创建一个名为 bar 的子目录:

    $ mkdir /var/www/bar

则请求 /test 的结果也是类似的:

    $ curl localhost:8080/test
    uri: /bar

在这种情况下,Nginx 在 try-files 阶段发现第一个参数 /foo 对应的文件不存在,就会转向检查第二个参数对应的文件系统对象(在这里便是目录 /var/www/bar/)。由于此目录存在,Nginx 就会把当前请求的 URI 改写为第二个参数的值,即 /bar(注意,原始参数值是 /bar/,但 try_files 会自动去除末尾的斜杠字符)。

 

    这一组实验所产生的“调试日志”如下:

    $ grep trying logs/error.log
    [debug] 4223#0: *1 trying to use file: "/foo" "/var/www/foo"
    [debug] 4223#0: *1 trying to use dir: "/bar" "/var/www/bar"

我们看到,try_files 指令在这里只检查和处理了它的前两个参数。

 

    通过前面这几组实验不难看到,try_files 指令本质上只是有条件地改写当前请求的 URI,而这里说的“条件”其实就是文件系统上的对象是否存在。当“条件”都不满足时,它就会无条件地发起一个指定的“内部跳转”。当然,除了无条件地发起“内部跳转”之外,try_files 指令还支持直接返回指定状态码的 HTTP 错误页,例如:

    try_files /foo /bar/ =404;

这行配置是说,当 /foo 和 /bar/ 参数所对应的文件系统对象都不存在时,就直接返回 404 Not Found 错误页。注意这里它是如何使用等号字符前缀来标识 HTTP 状态码的。

RFID管理系统集成商 RFID中间件 条码系统中间层 物联网软件集成