• openresty开发系列35--openresty执行流程之5内容content阶段


    openresty开发系列35--openresty执行流程之5内容content阶段

    content 阶段

    ---init阶段---重写赋值---重写rewrite---access

    content 阶段属于一个比较靠后的处理阶段,运行在先前介绍过的 rewrite 和 access 这两个阶段之后。
    当和 rewrite、access 阶段的指令一起使用时,这个阶段的指令总是最后运行,例如:

    location /content {
        # 重写阶段
        set $age 1;
        rewrite_by_lua "ngx.var.age = ngx.var.age + 1";

        # 访问阶段
        deny 127.0.0.1;
        access_by_lua "ngx.var.age = ngx.var.age * 2";

        # 内容阶段
        echo "age = $age";
    }

    启动nginx  ,访问 输出 age = 4

    改变它们的书写顺序,也不会影响到执行顺序。其中,
    set 指令来自 ngx_rewrite 模块,运行于 rewrite 阶段;
    而 rewrite_by_lua 指令来自 ngx_lua 模块,运行于 rewrite 阶段的末尾;
    接下来,deny 指令来自 ngx_access 模块,运行于 access 阶段;
    再下来,access_by_lua 指令同样来自 ngx_lua 模块,运行于 access 阶段的末尾;

    最后,echo 指令则来自 ngx_echo 模块,运行在 content 阶段

    ----------------------------------------------

    一)content_by_lua

    语法:content_by_lua <lua-script-str>
    默认值:无
    上下文:location, location if
    说明:行为类似与一个“content handler”,给每个请求执行定义于lua-script-str中的lua code。
    每一个 location 只能有一个“内容处理程序”,因此,当在 location 中同时使用多个模块的 content 阶段指令时,
    只有其中一个模块能成功注册“内容处理程序”。例如这个指令和proxy_pass指令不能同时使用在相同的location中

    --------------------------------

    例中的 set 指令和 rewrite_by_lua 指令同处于 rewrite 阶段,
    而 deny 指令和 access_by_lua 指令则同处于 access 阶段。
    但不幸的是echo指令,不能同时content_by_lua处于 content 阶段。

    考虑下面这个有问题的例子:

    location /content1 {
     echo "hello ";
     content_by_lua 'ngx.say("world")';
    }

    访问 http://10.11.0.215/content1 输出 world

    # 调换顺序
    location /content1 {
     
     content_by_lua 'ngx.say("world")';
     echo "hello ";

    }

    访问 http://10.11.0.215/content1 输出 hello

    这里,ngx_echo 模块的 echo 指令和 ngx_lua 模块的 content_by_lua 指令同处 content 阶段,
    于是只有其中一个模块能注册和运行这个 location 的“内容处理程序”:

    访问输出 world

    输出了后面的 content_by_lua 指令;而 echo 指令则完全没有运行。
    例中的 echo 语句和 content_by_lua 语句交换顺序,则输出就会变成 hello。
    所以我们应当避免在同一个 location 中使用多个模块的 content 阶段指令。

    location /content1 {
        echo hello;
        echo world;
    }

    这里使用多条 echo 指令是没问题的,因为它们同属 ngx_echo 模块,而且 ngx_echo模块规定和实现了它们之间的
    执行顺序。并非所有模块的指令都支持在同一个 location 中被使用多次,例如 content_by_lua 就只能使用一次,
    所以下面这个例子是错误的:

    location /content1 {
      content_by_lua 'ngx.say("hello")';
      content_by_lua 'ngx.say("world")';
    }

    报错nginx: [emerg] "content_by_lua" directive is duplicate

    正确写法:
    location /content1 {
        content_by_lua 'ngx.say("hello") ngx.say("world")';
    }

    ----------------------------------------------

    二)如果一个 location 中未使用任何 content 阶段的指令,会如何处理?

    静态资源服务模块

    1) ngx_index
    2) ngx_autoindex
    3) ngx_static

    location /content {
        
    }

    nginx会把当前请求的 URI 映射到文件系统的静态资源服务模块。
    当存在“内容处理程序”时,这些静态资源服务模块并不会起作用;反之,请求的处理权就会自动落到这些模块上。

    Nginx 一般会在 content 阶段安排三个这样的静态资源服务模块(除非你的 Nginx 在构造时显式禁用了这三个模块中
    的一个或者多个,又或者启用了这种类型的其他模块)。按照它们在 content 阶段的运行顺序,依次是 ngx_index
    模块,ngx_autoindex 模块,以及 ngx_static 模块。

    下面就来逐一介绍一下这三个模块

     ngx_index 和 ngx_autoindex 模块都只会作用于那些 URI 以 / 结尾的请求
     例如请求 GET /cats/,而对于不以 / 结尾的请求则会直接忽略,同时把处理权移交给 content 阶段的下一个模块。

     而 ngx_static 模块则刚好相反,直接忽略那些 URI 以 / 结尾的请求。

    以 / 结尾的请求   ===》  ngx_index 和 ngx_autoindex 模块 进行处理

    不以 / 结尾的请求   ===》  ngx_static 进行处理


    1) ngx_index 模块

    主要用于在文件系统目录中自动查找指定的首页文件,类似 index.html 和 index.htm 这样的,
     例如:

    location / {
        root   html;
        index  index.html index.htm;
    }

    当用户请求 / 地址时,Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html
    这两个文件。如果 index.htm 文件存在,则直接发起“内部跳转”到 /index.htm 这个新的地址;
    而如果 index.htm 文件不存在,则继续检查 index.html 是否存在。如果存在,同样发起“内部跳转”到 /index.html;
    如果 index.html 文件仍然不存在,则放弃处理权给 content 阶段的下一个模块。


    内部跳转:rewrite last 内容跳转
    ------------------------------------------

    验证 ngx_index 模块在找到文件时的“内部跳转”行为,看下面的例子

    location / {
        root   html;
        index  index.html;
    }

    location /index.html {
        set $a 32;
        echo "a = $a";
    }

    输出 a = 32

    为什么输出不是 index.html 文件的内容?首先对于用户的原始请求 GET /,Nginx 匹配出 location / 来处理它,
    然后 content 阶段的 ngx_index 模块在 html 下找到了 index.html,于是立即发起一个到 /index.html
    位置的“内部跳转”。在重新为 /index.html 这个新位置匹配 location 配置块时,
    location /index.html 的优先级要高于 location /,因为 location 块按照 URI 前缀来匹配时遵循所谓的
    “最长子串匹配语义”。这样,在进入 location /index.html 配置块之后,又重新开始执行 rewrite 、access、
    以及 content 等阶段。最终输出 a = 32

    -------------------

    如果此时把 /html/index.html 文件删除,再访问 / 又会发生什么事情呢?
    答案是返回 403 Forbidden 出错页。

    为什么呢?因为 ngx_index 模块找不到 index 指令指定的文件index.html,
    接着把处理权转给 content 阶段的后续模块,而后续的模块也都无法处理这个请求,
    于是 Nginx 只好放弃,输出了错误页,并且在 Nginx 错误日志中留下了类似这一行信息:

        [error] 28789#0: *1 directory index of "/html/" is forbidden

    ------------------
    2) ngx_autoindex 模块
    所谓 directory index 便是生成“目录索引”的意思,典型的方式就是生成一个网页,
    上面列举出 /html/ 目录下的所有文件和子目录。而运行在 ngx_index 模块之后的
    ngx_autoindex 模块就可以用于自动生成这样的“目录索引”网页。我们来把上例修改一下:

        location / {
            root /html/;
            index index.html;
            autoindex on;
        }
    此时仍然保持文件系统中的 /html/index.html 文件不存在。我们再访问 / 位置时,就会得到目录下的文件列表

    ---------------------
    3)ngx_static 模块
    在 content 阶段默认“垫底”的最后一个模块便是极为常用的 ngx_static 模块。

    这个模块主要实现服务静态文件的功能。比方说,一个网站的静态资源,包括静态 .html 文件、静态 .css 文件、
    静态 .js 文件、以及静态图片文件等等,全部可以通过这个模块对外服务。

    前面介绍的 ngx_index 模块虽然可以在指定的首页文件存在时发起“内部跳转”,但真正把相应的首页文件服务出去
    (即把该文件的内容作为响应体数据输出,并设置相应的响应头),还是得靠这个 ngx_static 模块来完成。

    ---------------------

    在下面例子

    location / {
        root html;
    }

    在html目录下创建hello.html文件

    访问http://10.11.0.215/hello.html

    不妨来分析一下这里发生的事情:location / 中没有使用运行在 content 阶段的模块指令,
    于是也就没有模块注册这个 location 的“内容处理程序”,处理权便自动落到了在 content 阶段“垫底”的
    那 3 个静态资源服务模块。

    a)首先运行的 ngx_index 和 ngx_autoindex 模块先后看到当前请求的 URI,/hello.html,并不以 / 结尾,
    于是直接弃权,
    b)将处理权转给了最后运行的 ngx_static 模块。ngx_static 模块根据 root 指令指定的“文档根目录”
    (document root),分别将请求 /hello.html 映射为文件系统路径 /html/hello.html,在确认这个文件存在后,
    将它们的内容分别作为响应体输出,并自动设置 Content-Type、Content-Length 以及 Last-Modified 等响应头。

  • 相关阅读:
    Git标签
    Git管理修改和撤销修改
    Git删除文件
    Git解决冲突
    Git的stash功能
    Git管理分支
    Git的多人协作模式
    Git相关指令
    LC7 整数翻转 + LC9 回文数
    LC1 两数之和
  • 原文地址:https://www.cnblogs.com/reblue520/p/11446470.html
Copyright © 2020-2023  润新知