① 基本概述
引言:
1)try_files是'ngx_http_try_files_module'所带的指令
特点:默认编译到'nginx的框架'中,无法修改
2)主要是能'替代'一些'rewrite的指令',提高'解析'效率
3)按'配置文件顺序'访问资源 -->相当于"或" ||
4)try_files指令'由'try_files模块提供的,try_files中可以使用'变量'
1) try_files有两种'语法'格式;如果多个'可选项',除去最后一个'选项'都是'file'
2) 先根据'root'和'alias指令'提供的值按照'try_files指令值'的顺序查找'对应file'是否存在
备注1: 可以通过以'反斜杠结尾/'的file让try_files查找'文件夹'是否存在
备注2: 如果能'找到file',以'找到的第一个file'作为条件'继续处理'当前请求
3) try_files指令提供的file'都不存在'那么就会发起'内部重定向'到uri
+++++++++++++ "深度思考" +++++++++++++
1) 对于'file'和'uri',try_files的处理有什么不同?
备注: try_files官网解读'file'和'uri'特殊字体标注
2) try_files的'处理流程'在nginx中具体是什么样的?
3) 查找到文件和文件'之后'呢?
4) 什么是'内部重定向'?
② 简单案例讲解
说明: error日志开启'debug'模式
++++++++++ "流程解读" ++++++++++
1) nginx是'先执行find_config阶段',寻找与'$uri'匹配的'location块',执行try_files指令
2) 尝试'file'的时候,根据'root'指令的值,都没有找到'指定'的文件
3) 最后尝试'uri'使用'内部重定向'的时候,请求的处理流程会被'回退'到find_config阶段
4) 这里使用'@lasturl'重新匹配location,进行'内部重定向'
备注: 这个重定向和外部重定向http的301不一样,它并'不会引起浏览器地址栏'的url的修改
补充: 目前已知可以导致'内部重定向'的几个指令 error_page internal、try_files、rewrite
++++++++ '分割线' ++++++++
③ 等价形式
遗留:
1)如果'uri'(try_files指令的最后一个参数),不是'命名的location'
2)那么$args'不会自动'保留,也即'参数丢失',如果你想保留$args,则必须'明确'声明
try_files $uri $uri/ /index.php?&$args
④ 思考摘录
⑤ 补充
背景: 前端经常使用到try_files指令,与root和alias搭配不适会导致不符合预期'404'、'重定向'
核心点: 主要是html中'内嵌的资源'是'相对'路径 -->'script、css、img、video等标签'
+++++++++++++ "补充以下几个知识点" +++++++++++++
1) 相关指令所处的'nginx阶段'以及指令的'先后'顺序
[1]、 try_files --> 'precontent阶段的try_files模块'
[2]、 alias | root --> 'content阶段的static模块'
[3]、 add_header --> 'content阶段之后的filter过滤模块'
2) try_files关于'file'或'uri'匹配之后,相关'变量'
[1]、$uri、$request_uri、$document_root、$realpath_root、$request_filename
[2]、模拟的时候通过添加'add_header'指令'自定义'响应头
3) 日志 -->"观察"
[1] rewrite_log on; #开启伪静态日志
[2] 开启 error.log debug日志观察
4) 资源内'嵌套'的相对路径的资源受'什么'影响
eg: html内嵌套'script、img'标签的相对资源
[1]、受$uri、$request_uri、$document_root、$realpath_root、$request_filename?
[2]、还是受'Referer'响应头影响
⑥ 匹配try_files的uri进行重定向
说明: 这三个案例相对于'root'指令
细节: 使用try_files'指定的uri'重新进行location匹配,相当于'原来的uri'丢失
说明: try_files 中指定'file'没有找到'对应的文件'
这里: root+file --> 为要在'磁盘'上最终的查找的资源
1) 如果'try_files'指令的前 N-1 个参数'file'所对应的'文件系统对象'都不存在
2) try-files 阶段就会立即发起"内部跳转"到最后一个参数(即第 N 个参数),尝试匹配所指定'uri'
3) 如果该'uri'确实能匹配上,则把'原始请求的uri'改写为'try_files指令中的uri'的值
说明: 地址栏'没有发生变化'说明是'内部重定向'
⑦ try_files的file匹配的是文件
1) file不是以'/'结尾,并且'不是'最后一个,则是'文件'匹配
2) 对于'file(try_files)',nginx'只会检查文件系统',而'不会'执行uri与location之间的匹配
1) 一旦 nginx 发现'某个文件系统对象(file)'存在
2) 就会在'try-files 阶段'把'当前请求(原始)的uri'改写为该'try_file指令'所对应的file参数
体现: '$uri'的值
⑧ try_files的file匹配的是目录
细节点: 发生'外部重定向'301
1) 如果'file'是目录[末尾带反斜杠/],uri'不包含'末尾的'斜杠'字符,也不会发生 "内部跳转"
2) 当'文件夹dir'存在,try_file会将'$uri'修改为 '/hello',接着给content阶段的模块处理
3) 这种场景'不会默认'加上index.html
案例2: try_files 中file为'/dir/'时,'不会自动'添加index.html
案例3: try_files 中file为'/dir/ceshi.html'时
补充: file是'文件',而不是'目录'
⑨ 综合错误案例
需求:
1) 访问'/wzj/ceshi/bb'返回'index.html',要求必须带'/wzj/ceshi'
2) 而'index.html'嵌套一些'相对'资源,要求'正确'返回
备之说明: 这里使用了'alias'和'try_files'结合
++++++++++++ "debug级别下 error的日志" ++++++++++++
+++++++++ "加载index.html中的images/cat.gif资源" +++++++++
细节点: 此时的请求url还是'/wzj/ceshi/bb'
++++++++++++++ "说明: 以下是acces..log的日志" ++++++++++++++
思考:请求url是'/wzj/ceshi/bb',为什么是'如下'的加载资源?
[1]、加载'资源1'的url: /wzj/ceshi/images/cat.gif
[2]、加载'资源2'的url:/wzj/ceshi/js/ceshi.js
细节点: 'bb'丢失
++++++++++++++ "说明: 以下是acces..log的日志" ++++++++++++++
思考请求url是'/wzj/ceshi/bb/',为什么是'如下'的加载资源?
[1]、加载'资源1'的url: /wzj/ceshi/bb/images/cat.gif
[2]、加载'资源2'的url:/wzj/ceshi/bb/js/ceshi.js
⑩ 正确做法
说明: contain variables, except $document_root and $realpath_root之外的
当 nginx location 正则 alias和 try_files, 存在排斥情况
if (!-e $request_filename) {
rewrite ^(.*)$ /index.php?s=$1 break;
}
⑪ 补充
#开启伪静态日志,方便调试
rewrite_log on; -->观察
以及 error.log debug日志观察 -->是否二选一观察
nginx中的try_files以及root、alias的使用
二 mirror模块
① 概述
细节点:
1)不同于'auth_request'的子请求,这个子请求是'异步'的 -->'sub_request'
2)换句话说'不需要等待'copy过去请求流量的返回结果
③ 案例讲解
④ 应用场景
镜像模块:创建一份'镜像'流量,可以在'测试'或者'开发'环境中使用
补充:做'简单'的流量拷,有'多个环境'需要处理用户流量,一般用在'测试'上
备注: 虽然'不常用',但要了解应用场景