nginx(四十三)precontent阶段的模块学习 核心try_files指令

一   try_files

①  基本概述

春哥的try_files解读 

引言： 

  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'响应头影响

agentzh大神关于try_files的解读 

⑥  匹配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

⑩  正确做法 

alias支持变量 

说明： contain variables, except $document_root and $realpath_root之外的

当 nginx location 正则 alias和 try_files, 存在排斥情况

HTML5 History 模式

if (!-e $request_filename) {

    rewrite ^(.*)$ /index.php?s=$1 break;

}

⑪  补充

nginx try_files流程解析

伪静态是个啥

  #开启伪静态日志，方便调试

  rewrite_log on;  -->观察

  以及 error.log debug日志观察 -->是否二选一观察

 nginx中的try_files以及root、alias的使用 

 服务器被入侵的排查

二   mirror模块

①  概述

细节点： 

  1）不同于'auth_request'的子请求,这个子请求是'异步'的  -->'sub_request'

  2）换句话说'不需要等待'copy过去请求流量的返回结果

②  mirror   mirror_request_body

③  案例讲解

④  应用场景

镜像模块：创建一份'镜像'流量,可以在'测试'或者'开发'环境中使用

补充：做'简单'的流量拷,有'多个环境'需要处理用户流量,一般用在'测试'上

备注： 虽然'不常用',但要了解应用场景