0%

有些童鞋的误区:

  • location 的匹配顺序是“先匹配正则,再匹配普通”。

矫正: location 的匹配顺序其实是“先匹配普通,再匹配正则”。我这么说,大家一定会反驳我,因为按“先匹配普通,再匹配正则”解释不了大家平时习惯的按“先匹配正则,再匹配普通”的实践经验。这里我只能暂时解释下,造成这种误解的原因是:正则匹配会覆盖普通匹配(实际的规则,比这复杂,后面会详细解释)。

  • location 的执行逻辑跟 location 的编辑顺序无关。

矫正:这句话不全对,“普通 location ”的匹配规则是“最大前缀”,因此“普通 location ”的确与 location 编辑顺序无关;但是“正则 location ”的匹配规则是“顺序匹配,且只要匹配到第一个就停止后面的匹配”。

“普通 location ”与“正则 location ”之间的匹配顺序是?先匹配普通 location ,再“考虑”匹配正则 location 。注意这里的“考虑”是“可能”的意思,也就是说匹配完“普通 location ”后,有的时候需要继续匹配“正则 location ”,有的时候则不需要继续匹配“正则 location ”。两种情况下,不需要继续匹配正则 location :

  1. 当普通 location 前面指定了“ ^~ ”,特别告诉 Nginx 本条普通 location 一旦匹配上,则不需要继续正则匹配;
  2. 当普通 location 恰好严格匹配上,不是最大前缀匹配,则不再继续匹配正则。

总结一句话: 「正则 location 匹配让步普通 location 的精确匹配结果;但覆盖普通 location 的宽泛匹配(最大前缀匹配)结果」。

批注:Web服务器在对待URL匹配的问题上,区分两大类:

  • 普通匹配: 没有通配符的情况下,采用Radix Tree算法,遵循最大前缀匹配原则,匹配跟URL的编辑顺序无关。
  • 正则匹配: 支持通配符和正则表达式,采用Filter Chain算法,遵循顺序匹配,且通常命中一个立即返回,匹配跟URL的编辑顺序相关。在Java领域,Spring MVC框架中典型的 AntPathMather.java

很多Web框架,都只支持一种匹配。而nginx则两种都支持。并且遵循「普通优先,但正则可覆盖普通」

阅读全文 »

Nginx 的虚拟主机技术有3种:

阅读全文 »