一 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关系