nginx(七十一)root、alias、index、try_files关系指令再探

一 root、alias、index、try_files辨析

说明： 这个系列很适合'前端人员'进阶学习

① 前言回顾

章神的博客

try_files基础知识 配置try_files实现内容重定向

root和alias指令辨析

​强调： 

  1) index只能处理以'/'结尾的'$uri'请求

  2) ​index指令'有点'在location中判断请求是否'是以/'结尾,才'起作用'

  也即：'if($uri ~ /$) {set $uri = "${uri}one_index_value"}',进行'internal重定向'

index和autoindex指令回顾

absolute_redirect absolute_redirect port_in_redirect 响应Location形式

try_files的语法规则

+++++++++++ try_files和index指令'对比'分析 +++++++++++

1) 从'11个'阶段来看,try_files比'index'指令优先级高

   [1]、 try_files 指令'本质'上只是'有条件地改写当前请求的 URI'

   备注： 

      1) 这里说的'条件'其实就是'文件系统上的对象'是否存在

      细节点：'file'则直接'返回','directory'还是会进行'301的Location',啥也不是'下一个'
       
      2) 当"条件"都不满足时,它就会'无条件[最后的值作为$uri]'发起一个指定的'内部跳转'

   [2]、index 首先判断'$uri'是否是以'/'结尾,然后判断'静态资源是否存在'

      细节点：存在则改变'$uri',不存在则下一个'index_value';

2) 都是处理'访问路径'和实际'物理'文件'不匹配'的场景下

3) 如果返回内容的问题,都涉及'internal内部跳转'的问题

++++++++++++++++  content '静态阶段'的运行顺序  ++++++++++++++++

依次是 'ngx_index' 模块 --> 'ngx_autoindex' 模块 --> 以及 'ngx_static' 模块

nginx 301重定向踩坑记录 深度硬核文:nginx的301重定向处理过程分析

小知识： 如果'没有location'与uri匹配,则才是真正的'基于root指令'的'静态'资源查找

② nginx从301到403两次请求

++++++++++ "默认的老六行为" ++++++++++

index index.html;

root html;        --> 相对'--prefix的路径','rpm安装'默认是'/usr/share/nginx'

+++++++++ "案例讲解" +++++++++

这里： 'user kiosk;',不涉及'try_files'指令

++++++++++ "从access_log的debug日志观察过程" ++++++++++

重点： nginx'主动'设置301 Moved Permanently状态码,并且给了'Location'响应头

1) 由于'301'重定向,客户端发起了'两次'请求

思考： 为什么'nginx主动设置301 Moved Permanently'?

'原理'解读：

  1）用户在'地址栏'输入url地址,nginx没有找到'(alias|root)、location、uri'作用后的资源

  2) 先做为'文件file'查找,'没有'找到,但是'nginx'发现最后的部分是一个'目录directory'

  3) 则本次访问的'响应'状态码会被设置成301,并在Response header里'增加一个Location'

  4) 如果是'目录',基于'$uri',在返回的'Location'增加了一个'斜杠/'

absolute_redirect指令影响Location是绝对还是相对url

思考:返回'403 Forbidden'出错页原因?

 1) 因为ngx_index 模块'找不到' index 指令指定的'文件'

 2) 接着把处理权转给 content 阶段的'后续'模块,而后续的模块也都'无法处理'这个请求

 3) 于是 nginx 只好'放弃',输出了'错误页',并且在 nginx '错误日志'中留下了类似这一行信息：

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

 4) 所谓 directory index 便是生成"目录索引"的意思

 通俗：典型方式就是'生成一个网页',上面列举出'xxx'目录下所有文件和子目录

403报错原因

nginx出现403的三种行为

③ index指令internal内部重定向探究

细节： '内部'重定向与'$uri'强相关

通俗： 对于'index指令',基于'$uri'进行'internal 内部重定向'

+++++++++++++ "官方案例太模糊,这里自己举例说明" +++++++++++++

利用： location 'regular和prefix' 匹配的优先级'说明'

思考： 为什么'没有'返回'88888888.html'文件的内容?

补充： curl -L 会基于'Location响应头'重新发请求,实际进行了'两次'请求,这里只截图了'第二次'

完全理解location中的index

补充： 千万'不要'使用 'location = /jane'精准形式,否则会导致'301重定向'的时候,'不能'匹配

重点：'rewrite指令' 发生'内部重定向',以及'proxy_pass'发生转发'发生'在查找'静态资源'之前

++++++++++++++  "分割线"  ++++++++++++++

问题： 什么条件下'index'指令符合我们的'预期'? 下面的案例补充"对比"说明

重点： internal '内部重定向'时,'$uri'为'/jane/8888888.html',此时跟'root'结合

核心： index'内部重定向'后重新进行'find_location',又找到'location /jane'

④ index指令值其它细节

index更加详细的探讨

1) index指令值'可以'使用'变量'                  --> 可以根据'请求相关信息',自定义"首页"

2) index指令值以'/绝对路径'开头和'不以/'开头的区别  --> "重点探讨"

  备注： 指令值可以是'相对'路径,基于原始'$uri'拼接;也可以是'绝对'路径,绝对路径只能'放在最后'

  补充： 'alias'只能是'location'级别指令

+++++++++++ "案例讲解"  +++++++++++

+++++++++++ "下面配置特殊点" +++++++++++ 

1) 官方'建议'： location如果使用'regular'匹配,并且'location'内使用'alias'要求

   [1]、location中使用'正则补获'

   [2]、alias组成部分'应该'使用'正则引用'

2) 这里： location使用正则,没有'补获',alias使用'裸'字符串

   备注： nginx'没有'报错,但是出现下面'诡异'的行为

3) 不涉及'try_files'指令

+++++++++++ 现象： "301重定向次数过多探究(死循环)" +++++++++++

++++++++++ "第一次请求" ++++++++++

  0) 首先由于'$uri'为'/jane',不是以'/'结尾

  1) 接着根据'uri、location、alias'进行'资源'的查找

  2) 最终查找'/usr/share/nginx/html/index_demo/'

  强调： 由于'location'使用'正则',导致不去考虑'原始'的uri,始终以'alias解析值'作为最终查找

  3) 发现'index_demo资源'不是一个'文件',是一个'目录 http dir'

   备注： 通过对'$uri'加'/'表示请求'目录资源'

  4) 进行'301'重定向

 注意： '此次'重定向的'Location'为'/jane/',index指令并'没有'起作用

++++++++++ "第二次请求" ++++++++++

1) 由于'301'重定向,客户端'第二次'请求 -->$uri: '/jane/'

2) 匹配'location ~ /jane',由于'index的优先级'比try_files'高',先判断'$uri是否以/结尾'

   备注： '/jane/'以'/'结尾,所以'index'指令起作用了,按照'顺序'作用

   细节： 由于'第一个'是相对路径,会基于'$uri'进行拼接,判断'资源是否存在'

   接着： 如果'资源存在',拼接得到新的$uri -->'/jane/hello.html'

   继续： 进行'internal'重定向,重新进行'find_location'又找到'location ~ /jane'

3) 此时$uri为'/jane/hello.html',不是以'/'结尾,则'try_files'开始起作用

   首先： 由于location使用'正则',直接以'alias解析值'作为最终的资源,不管'$uri'了

   也即： 此时查找'/usr/share/nginx/html/index_demo/',发现是一个'目录'资源

   细节： nginx'判断目录方式'是最终映射的'资源形式'是以'/'结尾,并'不一定'真是一个目录

4) index_demo是目录,后续准备'301 Moved Permanently',Location为'最终$uri+/'

   现象： Location为 '/jane/hello.html/'

++++++++++ "第三次请求" ++++++++++

++++++++++ "第n次请求" ++++++++++

1) 由于$uri'每次都是以/'结尾,所以每次都是'index'起作用,改变'$uri[之后不是以/结尾]'

2) 然后利用'alias和try_files'共同查找'静态'资源

++++++++ "一直内部重定向了50次" ++++++++

观察： "$uri"的变化

原理解读

++++++++++++  对比'实验'理解 ++++++++++++

细节点： 如果根据'root|alias'之后发现'文件资源存在',直接返回'200状态码',结束该次请求

前提： '$uri'不是以'/'结尾的,否则'try_files、(root|alias)'都不起作用

'客户端'访问： curl -L -s http://index.wzj.com:8066/jane

alias只是'uri映射后'进行后的资源,可能是'文件'或'目录'

1) nginx判定'资源 http filename'资源类型;首先判断'文件'是否存在,存在则'直接返回'

2) 如果文件'不存在',则判定是否是'目录 http dir'资源;
  
   [1]、如果'是'返回'301'进行'下一次'客户端请求

   [2]、如果'不是'呢返回'404'

③ location和alias的搭配问题

1) location使用'正则'与alias'结合'

条件：正则中必须'补获',alias中必须'引用',否则'引起'一系列的'非期望'的意外;'reload'不报错

注意：如果'location'中使用'正则',而'alias'单纯'裸'字符串,会产生'意外','进制'使用

建议： 如果location使用'正则',建议使用'root',尽量不要使用'alias'

+++++++++++ "现象解读" +++++++++++

1) 第一次请求'$uri'不是以'/'结尾,由于'location'使用'regular',使用'alias'解析值进行查找

细节点： alias'之后'存在'/usr/share/nginx/html/img/'目录资源,$uri会进行'加/'-->'301'

2) 第二次请求$uri以'/'结尾,使用默认index,导致内部重定向,此时已经'匹配不上'当前的location

3) 由于'没有'合适匹配location,此时利用'默认root指令'和此时的$uri拼接作为最终静态资源的查找

alias和location不合理匹配导致目录穿越漏洞

1) 目录通过'..穿越'--> 'location + alias' --> location和alias一个'带/',一个'不带/'

2) 解决策略:  location和alias要么都带'/',要么都不带'/'

④ try_files再探

一个常见需求的nginx配置踩雷

1) 'try_files'可以和'root|alias'配合使用           --> '见官网'

备注：一般用过'try_files $uri $uri/ ...' 改变nginx'301和404'行为
​
2) 实现'伪静态'采用 'root+try_files[@形式]' 就够了

备注： @ 'named location'可以使用'proxy_paas'之类的

3) try_files使用户可以'自定义'映射'查找资源',而不是'nginx默认的先找文件,再找目录之类的'

4) 细节点: 如果配置了'$uri $uri/ @other',在'$uri/'的时候是'不会'进行'301'重定向了

5) try_files 'uri' 有三种形式

   [1]、/something、'@named location'、'=code'

   [2]、'@named location'会默认保留'$args';其它形式如果要携带,必须显示指定'$args'

6) try_files 改变'$uri'的两种方式

 [1]、如果'file'之后是'目录'资源,则会进行'301'重定向,并以try_files对应的'value'值为$uri

 [2]、如果轮到'uri',则此时'$uri'为try_files最后的,进行'internal'内部重定向

index和try_files的区别 案例说明

+++++++++++++  "回归try_files的本质 --> 解决什么问题?"  +++++++++++++

 1) 如果轮到'try_files file',基于'root|alias'进行'查找'静态资源

 2) 如果轮到'index uri',直接将'$uri'变为'index指令中的uri',进行'internal'重定向

  只有'最后的value'才会改变'$uri'的方式,进行'资源'的'internal'内部重新'find_config'

  本质： '涉及最后的回退URI',是通过'rewrite'改变'$uri',然后进行'internal'重新匹配

 3) 最佳实践：try_files $uri $uri/ ... 

    1) 如果'$uri'资源不存在,进行下一个file '$uri/'的查找,不会直接出现'404'

    2) 如果判断加'/'判断是'目录',将第'二个value',这里是'Location $uri/'进行'301'重定向

    3) 如果'$uri/'也不存在,进行最后的'回退URI'进行内部'internal'重定向

if return rewrite 和try_files 都可以触发nginx 的rewrite

try_files指令高级说明

try_files 指令可以解决'vue或react框架'的history路由模式报'404或500'问题

⑤ 遗留

1) 需求：

 [1] 请求：/a/b/c/d/e/f '返回' register.html 

 [2] 里面加载了几个相对路径的资源'wzj.png java.css' 

 [3] 目的: 想使用'alias'+'index'

vue的history和hash模式

⑥ $uri、try_files、index关系

⑦ internal 、index、try_files关系