一次跨域问题总结-options的重要性

前后端分离至今，跨域问题已经是个很常见的问题，到今天技术已经非常成熟了。通常在nginx做好header头就可以了。但是最近因为运维觉得修改nginx配置太麻烦，线上机子又比较多【我们这边还没有容器化，也没有自动化运维，运维就一个人】，于是让我们在php层做处理。本来以为很简单，结果却出乎意料的让一个老程序员踩了坑，于是就有了这篇文章。

先来看看几个常见的header头：

Access-Control-Allow-Origin:*;

Access-Control-Allow-Methods:GET, POST, PUT,DELETE,PATCH,OPTIONS;

Access-Control-Allow-Headers:*;

正常不带cookie的这样就行了；如果跨域带cookie,则配置如下：

Access-Control-Allow-Credentials：true;

这个时候Access-Control-Allow-Origin:*;就不能配置成*了，必须要指定域名

nginx中配置示例：

if ($http_origin ~* (http?://.*\.test\.com$)) {

           add_header Access-Control-Allow-Origin $http_origin;
           add_header 'Access-Control-Allow-Credentials' 'true';
           add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';
      }

正常情况下，这就可以解决问题了，是吧。。。我也这么认为的。。。但是这次是nginx这边不加配置。。。

-------------------------------------------------------这是分隔线-----------------------------------------------------------------------

问题来了，nginx去掉了该配置，header头由php下发，但是前端就是调不通了。。。前端说是后端问题，后端这边说前端问题。。。

本人一直在忙于别的项目，本以为这个小问题随便弄弄就好了，结果发现这个项目一直卡着这个小问题上。。。（本来已经测试完毕了，奈何运维说线上服务器太多，测试环境也要跟线上一样，不加header头，于是接口一下子跨域都不通了。。。唉，一下子又把问题抛到了我这边。。。）

本人从事技术好多年了，凭借多年的经验，觉得这个问题有必要深究一下，于是把手上的活忙的差不多了，就来研究这个问题了。。。期间有不少发现，网上的文章也不多，于是就有了这个文章。

本着求真的原则，我自己写了个简单的前端，用ajax做了一个简单的跨域请求，结果发现，可以正常请求，header头也正常下发。。。于是觉得这是前端问题，就去找前端。。。【排除服务器配置问题】

前端说不对。。。他每次请求之前还有个options请求，我这边只有一个请求，情况不一样。。。

于是百度了一下。。。果然发现了问题

因为前端那边增加了很多自定义的头信息，对于复杂请求，会出现一次预请求，就是所谓的options请求。。。如果options没有返回对应的头信息，那正常的请求就无法请求了，于是我就检查了options请求，果然被后端的业务框架给非正常返回了【即没有返回指定的header头信息】。。。问题找到了，后面解决起来就很轻松了。

 

总结：这个问题其实也不复杂，只是之前我们都依赖于nginx配置，这种问题就没深究过，到了真正遇到的时候，总是喜欢犯经验主义的错误。