引子
前后端分离这个问题，对cors的应用不断增多，暴露出的问题也接踵而至。
正所谓虑一千次，不如去做一次。 犹豫一万次，不如实践一次，本篇主要讨论在发送ajax请求，头部带上自定义token验证验证，暴露出的跨域问题。
先说说定义
CORS：跨来源资源共享（CORS）是一份浏览器技术的规范，提供了 Web 服务从不同网域传来沙盒脚本的方法，以避开浏览器的同源策略，是 JSONP 模式的现代版。与 JSONP 不同，CORS 除了 GET 要求方法以外也支持其他的 HTTP 要求。用 CORS 可以让网页设计师用一般的 XMLHttpRequest，这种方式的错误处理比JSONP要来的好，JSONP对于 RESTful 的 API 来说，发送 POST/PUT/DELET 请求将成为问题，不利于接口的统一。但另一方面，JSONP 可以在不支持 CORS 的老旧浏览器上运作。不过现代的浏览器（IE10以上）基本都支持 CORS。
预检请求（option）:在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求(一般都是浏览检测到请求跨域时，会自动发起)，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。
1OPTIONS /resources/post-here/ HTTP/1.1 2Host: bar.other 3Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 4Accept-Language: en-us,en;q=0.5 5Accept-Encoding: gzip,deflate 6Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 7Connection: keep-alive 8Origin: http://foo.example 9Access-Control-Request-Method: POST 10Access-Control-Request-Headers: X-PINGOTHER, Content-Type
服务器所返回的 Access-Control-Allow-Methods 首部字段将所有允许的请求方法告知客户端。该首部字段与 Allow 类似，但只能用于涉及到 CORS 的场景中。
问题描述
话不多说，先上代码：
1前端（ajax库：vue-resource） 2 userLogin:function(){ 3 this.$http({ 4 method:'post', 5 url:'http://localhost:8089/StockAnalyse/LoginServlet', 6 params:{"flag":"ajaxlogin","loginName":this.userInfo.id,"loginPwd":this.userInfo.psd}, 7 headers: {'Content-Type': 'application/x-www-form-urlencoded'}, 8 credientials:false, 9 emulateJSON: true 10 }).then(function(response){ 11 sessionStorage.setItem("token",response.data); 12 this.isActive =false; 13 document.querySelector("#showInfo").classList.toggle("isLogin"); 14 }) 15 } 16后端相关配置： 17 response.setHeader("Access-Control-Allow-Origin", "http://localhost"); //允许来之域名为http://localhost的请求 18 response.setHeader("Access-Control-Allow-Headers", "Origin,No-Cache, X-Requested-With, If-Modified-Since, Pragma, Last-Modified, Cache-Control, Expires, Content-Type, X-E4M-With, userId, token"); 19 response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE"); //请求允许的方法 20 response.setHeader("Access-Control-Max-Age", "3600"); //身份认证(预检)后，xxS以内发送请求不在需要预检，既可以直接跳过预检，进行请求(前面只是照猫画虎，后面才理解)
关于上面一段代码，是我的用户首次登录认证，生成token令牌，保存在sessionStorage中，供后面调用；需要说明的是，前端服务器地址是：localhost:80,后端服务器地址：localhost:8089，所以前后端涉及到跨域，自己在后端做了相应的跨域设置：response.setHeader("Access-Control-Allow-Origin", "http://localhost"); 所以登录认证,安全的实现了跨域信息认证，后端相应发送回来了相应的token信息。
但获取到token后，想在需要的时候，在请求的头部携带上这个令牌，来做相应的身份认证，所以自己在请求中做了这些改动（有标注），后端没改动，源码：
1 checkIdentity:function(){ 2 let token =sessionStorage.getItem('token'); 3 this.$http({ 4 method:'post', 5 url:'http://localhost:8089/StockAnalyse/LoginServlet', 6 params:{"flag":"checklogin","isLogin":true,"token":token}, 7 headers: {'Content-Type': 'application/x-www-form-urlencoded'}, 8 headers:{'token':token}, //header中携带令牌信息 9 credientials:false, 10 emulateJSON: true 11 }).then(function(response){ 12 console.log(response.data); 13 }) 14 }
但实际上在devtools打印了如下错误信息：Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.仔细想一想，好像，似乎这个问题遇到过，还提过问，确实提过。但这次的设置和上次一样，就在header里多加了一个自定义token，但却报了和上次没有设置headers: {'Content-Type': 'application/x-www-form-urlencoded'}一样的错误信息，于是，不知所措，算了，重头再来，好好百度，研究一下cors跨域。
理论学习
运气不错，找到了一篇文章，文章讲的很细，也找到自己问题的所在：触发 CORS 预检请求。引用原文的话加以自己总结：跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request：似曾相识有没有？诶，对，上面那个错误信息中，就有一个这样陌生的词汇），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。所以跨域请求分两种：简单请求和预检请求。一次完整的请求不需要服务端预检，直接响应的，归为简单请求；而响应前需要预检的，称为预检请求，只有预检请求通过，才有接下来的简单请求。对于那些是简单请求，那些会触发预检请求，文章做了详细的总结，这里列出触发预检请求的条件（不知道脑子为啥会想到那些会触发BFC的条件），不要跑题，原文是这样总结的：
1当请求满足下述任一条件时，即应首先发送预检请求： 2使用了下面任一 HTTP 方法： 3PUT 4DELETE 5CONNECT 6OPTIONS 7TRACE 8PATCH 9人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为： 10Accept 11Accept-Language 12Content-Language 13Content-Type (but note the additional requirements below) 14DPR 15Downlink 16Save-Data 17Viewport-Width 18Width 19 Content-Type 的值不属于下列之一: 20application/x-www-form-urlencoded 21multipart/form-data 22text/plain
问题分析
所以，再来看自己两次犯错（第一次是没有设置：headers: {'Content-Type': 'application/x-www-form-urlencoded'}, 第二次是设置自定义header，headers:{'token':token}。很巧，有没有，一次少，一次多，都点燃了导火索），其实都是触发了预检请求。对于第一次的错误，很好解决，增加headers: {'Content-Type': 'application/x-www-form-urlencoded'}，就解决了，关于Conten-Type的几种取值，你需要知道的。但对于第二个错误，好像没法向第一种那样，将预检请求转变为简单请求，所以，只有寻找方法怎么在后端实现相应的预检请求，来返回一个状态码2xx，告诉浏览器此次跨域请求可以继续。所以注意力转向后端。
关于JAVA实现预检请求，基本都是采用过滤器，不要问我为什么不是监听器或者拦截器（我就是个伪全栈，就不要相互为难了，自己百度之），自定义（copy）了一个filter,并在web.xml中进行了设置。源码：
1Filter接口实现部分： 2package stock.model; 3import java.io.IOException; 4import javax.servlet.Filter; 5import javax.servlet.FilterChain; 6import javax.servlet.FilterConfig; 7import javax.servlet.ServletException; 8import javax.servlet.ServletRequest; 9import javax.servlet.ServletResponse; 10import javax.servlet.http.HttpServletRequest; 11import javax.servlet.http.HttpServletResponse; 12import org.apache.commons.httpclient.HttpStatus; //这里需要添加commons-httpclient-3.1.jar 13public class CorsFilter implements Filter { //filter 接口的自定义实现 14 public void init(FilterConfig filterConfig) throws ServletException { 15 } 16 @Override 17 public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { 18 HttpServletResponse response = (HttpServletResponse) servletResponse; 19 HttpServletRequest request = (HttpServletRequest) servletRequest; 20 response.setHeader("Access-Control-Allow-Origin", "*"); 21 String token = request.getHeader("token"); 22 System.out.println("filter origin:"+token);//通过打印，可以看到一次非简单请求，会被过滤两次，即请求两次，第一次请求确认是否符合跨域要求（预检），这一次是不带headers的自定义信息，第二次请求会携带自定义信息。 23 if ("OPTIONS".equals(request.getMethod())){//这里通过判断请求的方法，判断此次是否是预检请求，如果是，立即返回一个204状态吗，标示，允许跨域；预检后，正式请求，这个方法参数就是我们设置的post了 24 response.setStatus(HttpStatus.SC_NO_CONTENT); //HttpStatus.SC_NO_CONTENT = 204 25 response.setHeader("Access-Control-Allow-Methods", "POST, GET, DELETE, OPTIONS, DELETE");//当判定为预检请求后，设定允许请求的方法 26 response.setHeader("Access-Control-Allow-Headers", "Content-Type, x-requested-with, Token"); //当判定为预检请求后，设定允许请求的头部类型 27 response.addHeader("Access-Control-Max-Age", "1"); // 预检有效保持时间 28 } 29 filterChain.doFilter(servletRequest, servletResponse); 30 } 31 @Override 32 public void destroy() { 33 } 34} 35web.xml配置部分 36<filter> 37<filter-name>cors</filter-name> 38<filter-class>stock.model.CorsFilter</filter-class> 39</filter> 40<filter-mapping> 41<filter-name>cors</filter-name> 42<url-pattern>/*</url-pattern> 43</filter-mapping>
关于Access-Control-Max-Age
最近又开始写java，再回来看这个，发现当时Access-Control-Max-Age设置了1.其实这样写有很大问题，因为每个复杂请求都会发两次。显然这样是当代所不能接受的，所以Max-Age的值适合设的大一些，具体多大很业务需求相关。另外Access-Control-Max-Age不是针对请求域名有效的，是请求的完成路径有效的，比如第一次发出www.exanple.com/api/corsGet,会产生一次options请求和一次post请求，然后我再请求一次，这时没有预检请求了，只有post请求。但再发送一次www.exanple.com/api/corsSave请求，会发现又产生了一次options请求和一次post请求，所以Access-Control-Max-Age不是针对相同的origin有效，而是针对相同的requestUrl有效。很重要哦。
结论
当在后端实现添加上面的源码后，皆大欢喜，问题得以解决，补上失败和成功,自己截下的两张请求响应图
仔细看请求响应失败发起响应那张图，在General的数据集中，可以看到方法是options，而非代码指定的post请求，所以这是一次浏览器发出的一次预检请求，让服务器确认此IP是否有访问的权限，如果有，服务器需要返回一个2xx的状态码给浏览器。紧接着再发起一次简单请求。如下面在devtools中的截取图片（为了对比清除，我把两次分别截取，做了拼接，因为不会做动态图）。可以看到同一个post请求，实际上产生了两次网络连接。
但关于cors,要去探索的，还有很多很多，所以遵循革命语录：实践（有时也可以是时间）是检验真理的唯一标准，是没有错的。后续有新的收获，再补充。
