nginxrewrite理解起来也挺费劲

网友投稿 588 2022-05-29

这周三,有个老同事和我讨论了一个 HTTPS 问题,实质上却是 Nginx 的 rewrite 规则问题,我仔细阅读了官方文档,发现解释的不是特别明了,逐写了这篇博文。

rewrite 的语法规则如下:

Syntax: rewrite regex replacement [flag]; Context: server, location, if

我们暂时不考虑 flag 参数,先从简单的说起,首先务必要理解的就是 rewrite 规则在 server 段和 location 段中语义是不一样的。

在一个 URL 请求中,rewrite 如果匹配到 regex,那么 URL 就会替换成 replacement,如果不考虑 flag,匹配规则是顺序执行的,即使匹配到了,仍然会继续匹配下去。

记住,如果 replacement 包含 “http://”, “https://”, or “$scheme”,那么匹配会理解终止,并直接重定向地址给客户端。

接下去说说 flag 可选参数,如果有 flag 参数,rewrite 会进一步处理指令。flag 参数有四个:

last:stops processing the current set of ngx_http_rewrite_module directives and starts a search for a new location matching the changed URI;

break:stops processing the current set of ngx_http_rewrite_module directives as with the break directive;

redirect:returns a temporary redirect with the 302 code;

permanent:returns a permanent redirect with the 301 code.

flag 参数如果是 redirect 或 permanent,那么处理就相对简单,立刻中止规则匹配,进行 302 或 301 跳转。

从文档看,last 和 break 看不出太大区别,我总结就是如果在 location 中配置 flag 是 last,立刻跳出本 location 的匹配,同时会顺序继续搜寻其他 location 的匹配,如果还没匹配到,还会继续搜寻本 location;而 break 跳出本 location 后就不会再匹配其它 location 了。通过个例子说明:

如果访问 https://www.simplehttps.com/a/,则返回 401;如果访问 https://www.simplehttps.com/b/,则返回 402。

接下去修改配置:

结果就是,不管访问 https://www.simplehttps.com/a/ 还是 https://www.simplehttps.com/b/,都返回 404。

那么如果 flag 配置在 server 段内,会发生什么呢?不管是 break 还是 last,其行为规则是一样的,不会有跳出的行为,会顺序执行。

那么文档中描述的死循环什么情况呢?以下的例子在 location 中就会死循环:

原因就在于 rewrite 匹配后还是 /download 开头,如果是 last,会继续走到 location /download/ { 段内,从而会死循环,最终产生 500 错误,所以这种情况下,建议将 last 修改为 break。

nginx的rewrite理解起来也挺费劲

其实事情也没有那么复杂,取决于你清楚自己想达到什么目标,然后在 last 和 break 之间取舍。

我的书《深入浅出HTTPS:从原理到实战》代码实例已经更新到 github 上了,地址是 https://github.com/ywdblog/httpsbook,欢迎一起讨论。也欢迎关注我的公众号(ID:yudadanwx,虞大胆的叽叽喳喳)。

本文转载自异步社区。

Nginx

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Redis干货分享 | 5个步骤构建优质Redis模块
下一篇:《猎豹行动:硝烟中的敏捷转型之旅》读书笔记DAY04:探路-敏捷深化 迈向常态
相关文章