在当前项目中，前端通过POST方式访问后端的REST接口时，发现两条请求记录，一条请求的Request Method为Options，另一条请求的Reuest Method为Post。想要解决这个疑惑还得从以下3个概念说起。

Http Options Method

RFC2616标准（现行的HTTP/1.1）中如下描述：

简而言之，OPTIONS请求方法的主要用途有两个：

1、获取服务器支持的HTTP请求方法；

2、用来检查服务器的性能。

CORS(跨域资源共享)

CORS是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，允许网页从不同的域访问其资源。而这种访问是被同源策略所禁止的。CORS系统定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。

使用CORS的方式非常简单，但是需要同时对前端和服务器端做相应处理。

1、 前端

客户端使用XmlHttpRequest发起Ajax请求，当前绝大部分浏览器已经支持CORS方式，且主流浏览器均提供了对跨域资源共享的支持。

2、 服务器端

如果服务器端未做任何配置，则前端发起Ajax请求后，会得到CORS Access Deny，即跨域访问被拒绝。

对于C#做如下配置可允许资源的跨域访问：

<system.webServer>
…







</system.webServer>

对于nodejs做如下配置可允许资源的跨域访问：

//设置CORS跨域访问
app.all(’ ’, function (req, res, next) {undefined
res.header(“Access-Control-Allow-Origin”, " ");
res.header(“Access-Control-Allow-Headers”, “X-Requested-With, accept, origin, content-type”);
res.header(“Access-Control-Allow-Methods”, “PUT,POST,GET,DELETE,OPTIONS”);
res.header(“X-Powered-By”, ’ 3.2.1’)
res.header(“Content-Type”, “application/json;charset=utf-8”);
next();
});

Access-Control-Allow-Origin:*表示允许任何域发起请求，如果只允许特定的域访问，则设置Access-Control-Allow-Origin:xxx为具体域名即可。

Preflighted Requests(预检请求)

Preflighted Requests是CORS中一种透明服务器验证机制。预检请求首先需要向另外一个域名的资源发送一个 HTTP OPTIONS 请求头，其目的就是为了判断实际发送的请求是否是安全的。

下面的2种情况需要进行预检：

1、 简单请求，比如使用Content-Type 为 application/xml 或 text/xml 的 POST 请求；

2、中设置自定义头，比如 X-JSON、X-MENGXIANHUI 等。

了解完这3个概念，其实答案已经了然了。

HTTP提供了一个与PUT方法对应的DELETE方法。一个DELETE请求将需要从Web服务器删除的内容指定为请求行中的资源部分。
DELETE方法唯一有趣的地方在于当你接收了一个标识为200 OK的响应的时候，那并不意味着指定的资源已经被删除了。那仅仅说明服务器接收到了删除资源的命令。这一例外允许了出于安全考虑的人为的干预

转自：http://blog.csdn.net/leikezhu1981/article/details/7402272

出于安全考虑，并不是所有域名访问后端服务都可以。其实在正式跨域之前，浏览器会根据需要发起一次预检（也就是option请求），用来让服务端返回允许的方法（如get、post），被跨域访问的Origin（来源或者域），还有是否需要Credentials(认证信息)等。那么浏览器在什么情况下能预检呢？

浏览器将CORS请求分为两类：简单请求（simple request）和非简单请求（not-simple-request）,简单请求浏览器不会预检，而非简单请求会预检。这两种方式怎么区分？

同时满足下列三大条件，就属于简单请求，否则属于非简单请求

1.请求方式只能是：GET、POST、HEAD

2.HTTP请求头限制这几种字段：Accept、Accept-Language、Content-Language、Content-Type、Last-Event-ID

3.Content-type只能取：application/x-www-form-urlencoded、multipart/form-data、text/plain

对于简单请求，浏览器直接请求，会在请求头信息中，增加一个origin字段，来说明本次请求来自哪个源（协议+域名+端口）。服务器根据这个值，来决定是否同意该请求，服务器返回的响应会多几个头信息字段，如图所示：上面的头信息中，三个与CORS请求相关，都是以Access-Control-开头。

1.Access-Control-Allow-Origin：该字段是必须的，* 表示接受任意域名的请求，还可以指定域名

2.Access-Control-Allow-Credentials：该字段可选，是个布尔值，表示是否可以携带cookie，（注意：如果Access-Control-Allow-Origin字段设置*，此字段设为true无效）

3.Access-Control-Allow-Headers：该字段可选，里面可以获取Cache-Control、Content-Type、Expires等，如果想要拿到其他字段，就可以在这个字段中指定。比如图中指定的GUAZISSO

非简单请求是对那种对服务器有特殊要求的请求，比如请求方式是PUT或者DELETE，或者Content-Type字段类型是application/json。都会在正式通信之前，增加一次HTTP请求，称之为预检。浏览器会先询问服务器，当前网页所在域名是否在服务器的许可名单之中，服务器允许之后，浏览器会发出正式的XMLHttpRequest请求，否则会报错。（备注：之前碰到预检请求后端没有通过，就不会发正式请求，然后找了好久原因，原来后端给忘了设置…）Java后端实现拦截器，排除Options

JAVA代码片段

就Content-Type为application/json为例：对比两张图片，一次预检请求，一 次正式请求：

很明显，请求头中预检请求不会携带cookie，正式请求会携带cookie和参数。跟普通请求一样，响应头也会增加同样字段。

一旦服务器通过了“预检”请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样。