Nginx 标签中有 3 篇文章
既上一篇文章记录了组内单页引擎升级路由为 History API 方式，考虑到不支持该方式的浏览器/WebView，需要多页降级。如果不对 Nginx 进行配置，就会出现404，因为多数通过pushState得到的 URL 并没有真实对应的资源。
采用 History API 方案的 URL 格式如下：
http[s]://hostname/resource/project/page[/view]?arg1=value1
其中 resource 为资源目录，该目录下放置各个不同的项目文件夹，每个项目对应一个 project 目录。一个 project 中可能会有多个单页应用，每个单页应用对应 URL 中的一个 page。一个单页应用下的不同视图分别对应一个 view。因为采用的单页引擎支持默认路由，所以 view 并非必需。
比如 A 项目下有一个 refund 的单页应用，对应的 HTML 资源为 refund.html，为了 URL 的美观，在 URL 中去掉 html 后缀名。refund 管理两个视图 detail 和
之前使用 History API 作为路由方案升级了组内单页视图引擎。完整的实现还需要 Nginx 的辅助配置，因为当页面刷新时，通过pushState到达的路由很可能并不存在对应的资源，所以要使同一个项目下的所有路由匹配到项目对应的单页资源。
其实主要的工作是对3种资源的 uri 配置 rewrite：
对应的配置如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# match img resource location ~ /resource/wa/([\w|-]+)/(img|page)/(.*) { rewrite ^/resource/wa/([\w|-]+)/(img|page)/(.*)$ /resource/$1/$2/$3 last; } location ~ /resource/wa/([\w|-]+)/([\w|-]+)/(img|page)/(.*) { rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)/(img|page)/(.*)$ /resource/$1/$3/$4 last; } # match HTML resource location ~ /resource/wa/([\w|-]+)/.* { rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)$ /resource/$1/$2.html last; rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)/([\w|-]+)$ /resource/$1/$2.html last; } |
其中/resource/wa/为所有项目所处的统一目录，第二级目录为项目所在目录，第三级对应项目下的某个单页，第四级为可选，且表示某个单页项目下的某个具体 view。
今天和同事讨论一个有关 nginx 中的location配置问题，就想查一下它的匹配规则。结果 Google 出的文章基本都是同一篇，而且各种莫名其妙的示例看得自己更云里雾里，索性上官网查文档，现对它的用法做个梳理。
|
1 2 |
location [ = | ~ | ~* | ^~ ] uri { ... } location @name { ... } |
这是location的使用方法，这里暂不考虑@的用法。
匹配规则其实可以分为两类：
prefix string：即前缀字符串匹配，包括= uri、^~ uri和uri三种形式。regex：即正则匹配，包括~ uri（大小写敏感）和~* uri（大小写不敏感）两种形式。nginx 对 location 的匹配流程为：
=规则并且=后的 uri 和请求的 uri 完全匹配，那么直接命中该条规则，然后立刻终止匹配；若无满足上述条件，则进行下一步。=规则，nginx 会持续遍历完成所有的 prefix string 类型规则。遍历完成后，如果有单个匹配的^~规则，则