CORS 专题

CORS（跨域资源共享，Cross-Origin Resource Sharing）
CORS其实出现时间不短了，它在维基百科上的定义是：跨域资源共享（CORS ）是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，容许网页从不一样的域访问其资源。而这种访问是被同源策略所禁止的。
CORS系统定义了一种浏览器和服务器交互的方式来肯定是否容许跨域请求。 它是一个妥协，有更大的灵活性，但比起简单地容许全部这些的要求来讲更加安全。

好比，
站点 http://domain-a.com 的某 HTML 页面经过 <img> 的 src 请求 http://domain-b.com/image.jpg。
网络上的许多页面都会加载来自不一样域的CSS样式表，图像和脚本等资源。

出于安全考虑，浏览器会限制从脚本内发起的跨域HTTP请求。
例如，XMLHttpRequest 和 Fetch 遵循同源策略。
所以，使用 XMLHttpRequest或 Fetch 的Web应用程序只能将HTTP请求发送到其本身的域。
为了改进Web应用程序，开发人员要求浏览器厂商容许跨域请求。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

同源策略， 即JavaScript只能访问同域下的内容

Same-origin policy
From Wikipedia, the free encyclopedia

In computing, the same-origin policy is an important concept in the web application security model.
Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
An origin is defined as a combination of URI scheme, hostname, and port number.
This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.

https://en.wikipedia.org/wiki/Same-origin_policy

而W3C的官方文档目前仍是工做草案，可是正在朝着W3C推荐的方向前进。

简言之，CORS就是为了让AJAX能够实现可控的跨域访问而生的。

 

 

 

 

浏览器的同源策略，便是浏览器之间要隔离不一样域的内容，禁止互相操做。

好比，当你打开了多个网站，若是容许多个网站之间互相操做，那么其中一个木马网站就能够经过这种互相操做进行一系列的非法行为，获取你在各个网站的相关信息，很明显这是不安全的，因此同源策略避免了不少这样的问题。

可是同时也带来了一些问题，好比有时候你想经过本身的网站去获取另外一个本身的网站的一些资料信息，可是因为二者域名不一样，因此就被同源策略隔离了，那么这个时候就须要了解一下浏览器的跨域问题。

 

跨域常见的两种方式，分别是jsonp和新推出的cors，即cross-origin resourse sharing，其实这货出现的时间也不短了，只是我如今才注意到而已。

先说说jsonp，先说个简单的例子再讲百度的例子。

咱们有个www.a.com的页面

<script type="text/javascript"
src="http://www.b.com?name=qiangzi"></script>
<script type="text/javascript">
function jsonp(json){
    alert(json[‘age’]);
}
</script>

 

这是请求 http://www.b.com?name=qiangzi 返回的js文件。

jsonp({'name':'qiangzi','age':20});

事先声明，我的没有实际的使用过jsonp去进行跨域操做，因此全部的分析都是猜测，如有不对请指出。

咱们来试着去分析上面的代码，a页面事先写好了一个回调函数，便是供咱们请求回的js回调的函数，这里的回调函数式alert参数组中的年龄。

咱们再看咱们的请求，首先咱们的请求是写在script标签里面的，因此说明正常来讲咱们请求回来的内容应该是一段js文件。接着看，咱们发现请求的时候同时传了一个参数过去name="qiangzi"，因此咱们基本能够猜想在www.b.com服务器那边，接收到a页面的请求，同时接收到传过来的name数据，根据这个数据进行相应的查询，找到了{name:"qiangzi",age:20}这样的一段数据以后，咱们的b服务器因而就构造了一段这样的js文件传给请求的页面

jsonp({'name':'qiangzi','age':20});

也就是在原页面输出咱们请求的name对应的年龄。很明显，咱们请求的script标签中的src不能写死，而应该是一个动态的插入name值的过程。

从前台写好回调函数，到根据请求的参数值构造请求连接，跨域服务器根据连接进行相应处理返回数据并执行回调函数，这整一个过程就是jsonp的过程，固然上述只是我我的猜测，毕竟没有去实现过，因此有错望大神们指出。

那么咱们按照这个思路再来看看百度搜索下拉框的jsonp跨域操做。

咱们在百度搜索框输入jsonp，立刻出现了下拉框，分别有jsonp json jsonp跨域等等，其实这一过程就是使用到了jsonp跨域处理，具体怎么过跨法，咱们打开F12，找到network这里能够看到这样的一个请求

也就是这个连接

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

点击咱们能够看到这样的一段东西

那么这样的一段东西实际上是什么呢？其实这就是咱们jsonp跨域请求回来的数据以及调用的函数。

接下来就按照咱们刚才的思路分析下整个过程。

首先，百度在前台写好了一个回调函数，便是接收跨域返回来的数据而且出现下拉框，把数据填充到下拉框中。当咱们在百度搜索的输入框（注意区分开此处的输入框和上句话中的下拉框）输入咱们要搜索的内容时，此时百度页面立刻获取咱们输入的值，并构造请求，即咱们上文中提到的

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

对于这一段请求，我我的看着都以为有点怕怕的，因此为了方便理解jsonp咱们简化下应该能够这样理解

https://sp0.baidu.com/su?wd=jsonp

服务器查询jsonp对应的联想关键词，并把这些关键词填充在一个数组中，而后把这个数组做为参数调用前台写好的回调函数，返回这段js文件给前台，而后咱们就看到了在搜索框输入jsonp而后下拉框出现一系列关键词的功能。

至此，关于jsonp的例子讲诉差很少结束。那么jsonp有哪些优缺点呢？

jsonp的优势是兼容全部的浏览器，不管是主流的仍是之前的。而它的缺点则是因为jsonp发起的请求是get方式的，即参数是填充在请求地址上，因此这种方式发送的数据有限制。

关于jsonp再补充点内容，其实不知道你们有没有想过，咱们使用的不少API接口，调用他们返回的数据，其实这一过程就是跨域了，由于咱们请求的是别的站点的数据，不作跨域处理咱们是不可能得到信息的，只是有时候咱们是按着API说明文档照写的因此忽视了这个

我这里有个国外的API，根据填写的邮编搜索邮编所对应的位置信息

http://www.geonames.org/postalCodeLookupJSON?postalcode=10504&country=US&callback=?

在这个API中咱们须要填写三个参数，一个是邮编号码，另外一个是对应的国家，而第三个就是咱们的回调函数。

这个是该API接口返回的数据

整个API调用的过程就是，咱们在前台写好一个callback函数，这个callback函数的功能就是根据咱们的需求而写，而后在构造请求的时候把这个callback函数的名称写在请求对应的callback上。至于其余的邮编号码国家这些固然也是在咱们前台页面构造的。构造完这些请求以后，当咱们发起请求的时候，API服务器端就会根据咱们的请求信息，拿到相应的数据，并把这些数据放到咱们写的回调函数对应的参数中传回来，并进行调用，整个API调用完毕。

 

说完了jsonp，接下来讲说cors跨域这玩意。

在前文看到同源策略的时候，不知道你们有没有想过，难道就不能让两个跨域的站点写一个秘密的协议，达成一种交易从而使得二者能够进行跨域操做获取数据之类的吗？嗯，我我的以为cors作的就是这件事。

关于cors在维基百科上的定义是这样的：跨域资源共享（CORS ）是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，容许网页从不一样的域访问其资源。而这种访问是被同源策略所禁止的。CORS系统定义了一种浏览器和服务器交互的方式来肯定是否容许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地容许全部这些的要求来讲更加安全。

要想实现cors跨域，须要作的就是两件事，一个是咱们的浏览器要支持cors跨域这一操做（主流谷歌和火狐均支持，ie版本要高于ie10才行），另外，咱们的服务器端必需要设置好Access-Control-Allow-Origin从而支持跨域操做。

cors相对于jsonp而言的好处就是支持全部的请求方式，不止是get请求，还支持post,put请求等等，而它的缺点就很明显，没法兼容全部的浏览器，对于要兼容到老式浏览器而言，仍是使用jsonp好点。

 http://www.cnblogs.com/jelly7723/p/5494330.html

 

序言：跨域资源共享向来都是热门的需求，使用CORS能够帮助咱们快速实现跨域访问，只需在服务端进行受权便可，无需在前端添加额外设置，比传统的JSONP跨域更安全和便捷。

1、基本介绍

简单来讲，CORS是一种访问机制，英文全称是Cross-Origin Resource Sharing，即咱们常说的跨域资源共享，经过在服务器端设置响应头，把发起跨域的原始域名添加到Access-Control-Allow-Origin 便可。

1. CORS工做原理

CORS实现跨域访问并非一蹴而就的，须要借助浏览器的支持，从原理题图咱们能够清楚看到，简单的请求（一般指GET/POST/HEAD方式，并无去增长额外的请求头信息）直接建立了跨域请求的XHR对象，而复杂的请求则要求先发送一个”预检”请求，待服务器批准后才能真正发起跨域访问请求。

根据官方文档W3C规范-CORS 的描述，目前CORS使用了以下头部信息：

注：请求头信息由浏览器检测到跨域自动添加，无需过多干预，重点放在Response headers，它能够帮助咱们在服务器进行跨域受权，例如容许哪些原始域可放行，是否须要携带Cookie信息等。

2. Request Headers（请求头）

• Origin

  表示跨域请求的原始域。

• Access-Control-Request-Method

  表示跨域请求的方式。（如GET/POST）

• Access-Control-Request-Headers

  表示跨域请求的请求头信息。

3. Response headers（响应头 ）

• Access-Control-Allow-Origin

  表示容许哪些原始域进行跨域访问。（字符数组）

• Access-Control-Allow-Credentials

  表示是否容许客户端获取用户凭据。（布尔类型）
  使用场景：例如如今从浏览器发起跨域请求，而且要附带Cookie信息给服务器。则必须具有两个条件：1. 浏览器端：发送AJAX请求前需设置通讯对象XHR的withCredentials 属性为true。 2.服务器端：设置Access-Control-Allow-Credentials为true。两个条件缺一不可，不然即便服务器赞成发送Cookie，浏览器也没法获取。正确姿式以下：

• Access-Control-Allow-Methods

  表示跨域请求的方式的容许范围。（例如只受权GET/POST）

• Access-Control-Allow-Headers

  表示跨域请求的头部的容许范围。

• Access-Control-Expose-Headers

  表示暴露哪些头部信息，并提供给客户端。（由于基于安全考虑，若是没有设置额外的暴露，跨域的通讯对象XMLHttpRequest只能获取标准的头部信息）

• Access-Control-Max-Age

  表示预检请求 [Preflight Request] 的最大缓存时间。

2、CORS实现跨域访问

受权方式

• 方式1：返回新的CorsFilter
• 方式2：重写WebMvcConfigurer
• 方式3：使用注解（@CrossOrigin）
• 方式4：手工设置响应头（HttpServletResponse ）

注：CorsFilter / WebMvcConfigurer / @CrossOrigin 须要SpringMVC 4.2 以上的版本才支持，对应SpringBoot 1.3 版本以上都支持这些CORS特性。不过，使用SpringMVC4.2 如下版本的小伙伴也不用慌，直接使用方式4经过手工添加响应头来受权CORS跨域访问也是能够的。附：在SpringBoot 1.2.8 + SpringMVC 4.1.9 亲测成功。

注：方式1和方式2属于全局CORS配置，方式3和方式4属于局部CORS配置。若是使用了局部跨域是会覆盖全局跨域的规则，因此能够经过@CrossOrigin注解来进行细粒度更高的跨域资源控制。

1. 返回新的CorsFilter（全局跨域）

在任意配置类，返回一个新的CorsFilter Bean，并添加映射路径和具体的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        //1.添加CORS配置信息
        CorsConfiguration config = new CorsConfiguration();
          //放行哪些原始域
          config.addAllowedOrigin("*");
          //是否发送Cookie信息
          config.setAllowCredentials(true);
          //放行哪些原始域(请求方式)
          config.addAllowedMethod("*");
          //放行哪些原始域(头部信息)
          config.addAllowedHeader("*");
          //暴露哪些头部信息（由于跨域访问默认不能获取所有头部信息）
          config.addExposedHeader("*");

        //2.添加映射路径
        UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
        configSource.registerCorsConfiguration("/**", config);

        //3.返回新的CorsFilter.
        return new CorsFilter(configSource);
    }
}

2. 重写WebMvcConfigurer（全局跨域）

在任意配置类，返回一个新的WebMvcConfigurer Bean，并重写其提供的跨域请求处理的接口，目的是添加映射路径和具体的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            //重写父类提供的跨域请求处理的接口
            public void addCorsMappings(CorsRegistry registry) {
                //添加映射路径
                registry.addMapping("/**")
                        //放行哪些原始域
                        .allowedOrigins("*")
                        //是否发送Cookie信息
                        .allowCredentials(true)
                        //放行哪些原始域(请求方式)
                        .allowedMethods("GET","POST", "PUT", "DELETE")
                        //放行哪些原始域(头部信息)
                        .allowedHeaders("*")
                        //暴露哪些头部信息（由于跨域访问默认不能获取所有头部信息）
                        .exposedHeaders("Header1", "Header2");
            }
        };
    }
}

3. 使用注解（局部跨域）

在方法上（@RequestMapping）使用注解 @CrossOrigin ：

@RequestMapping("/hello")
    @ResponseBody
    @CrossOrigin("http://localhost:8080") 
    public String index( ){
        return "Hello World";
    }

或者在控制器（@Controller）上使用注解 @CrossOrigin ：

@Controller
@CrossOrigin(origins = "http://xx-domain.com", maxAge = 3600)
public class AccountController {

    @RequestMapping("/hello")
    @ResponseBody
    public String index( ){
        return "Hello World";
    }
}

4. 手工设置响应头（局部跨域 ）

使用HttpServletResponse对象添加响应头（Access-Control-Allow-Origin）来受权原始域，这里Origin的值也能够设置为”*” ，表示所有放行。

@RequestMapping("/hello")
    @ResponseBody
    public String index(HttpServletResponse response){
        response.addHeader("Access-Control-Allow-Origin", "http://localhost:8080");
        return "Hello World";
    }

3、测试跨域访问

首先使用 Spring Initializr 快速构建一个Maven工程，什么都不用改，在static目录下，添加一个页面：index.html 来模拟跨域访问。目标地址: http://localhost:8090/hello

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8"/>
    <title>Page Index</title>
</head>
<body>
<h2>前台系统</h2>
<p id="info"></p>
</body>
<script src="webjars/jquery/3.2.1/jquery.js"></script>
<script>
    $.ajax({
        url: 'http://localhost:8090/hello',
        type: "POST",
        success: function (data) {
            $("#info").html("跨域访问成功:"+data);
        },
        error: function (data) {
            $("#info").html("跨域失败!!");
        }
    })
</script>
</html>

 

而后建立另外一个工程，在Root Package添加Config目录并建立配置类来开启全局CORS。

@Configuration
public class GlobalCorsConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**");
            }
        };
    }
}

接着，简单编写一个Rest接口 ，并指定应用端口为8090。

@SpringBootApplication
@RestController
public class YyWebApplication {

    @Bean
    public TomcatServletWebServerFactory tomcat() {
        TomcatServletWebServerFactory tomcatFactory = new TomcatServletWebServerFactory();
        tomcatFactory.setPort(8090); //默认启动8090端口
        return tomcatFactory;
    }

    @RequestMapping("/hello")
    public String index() {
        return "Hello World";
    }

    public static void main(String[] args) {
        SpringApplication.run(YyWebApplication.class, args);
    }
}

 

最后分别启动两个应用，而后在浏览器访问：http://localhost:8080/index.html ，能够正常接收JSON数据，说明跨域访问成功！！

尝试把全局CORS关闭，或者没有单独在方法或类上受权跨域，再次访问：http://localhost:8080/index.html 时会看到跨域请求失败！！

4、源码和文档

Github源码：SpringBoot-Cross-Orgin

专题地址：SpringBoot 从入门到上瘾

规范文档：W3C规范-CORS

传统文档：SpringMVC-CORS 使用手册

推荐阅读：跨域资源共享 CORS 详解 - 阮一峰

http://www.spring4all.com/article/177

 

 

概述

• CORS能作什么：

     正常使用AJAX会须要正常考虑跨域问题，因此伟大的程序员们又折腾出了一系列跨域问题的解决方案，如JSONP、flash、ifame、xhr2等等。

     本文介绍的CORS就是一套AJAX跨域问题的解决方案。

 

•  CORS的原理：

     CORS定义一种跨域访问的机制，可让AJAX实现跨域访问。CORS 容许一个域上的网络应用向另外一个域提交跨域 AJAX 请求。实现此功能很是简单，只需由服务器发送一个响应标头便可。

 

• CORS浏览器支持状况以下图：

       

     

　　喜闻乐见、普大喜奔的支持状况，尤为是在 移动终端上，除了opera Mini；

　　PC上的现代浏览器都能友好的支持，除了IE9-，不过前端工程师对这种状况早应该习惯了...

     

 

CORS启航

 

　　假设咱们页面或者应用已在 http://www.test1.com 上了，而咱们打算从 http://www.test2.com 请求提取数据。通常状况下，若是咱们直接使用 AJAX 来请求将会失败，浏览器也会返回“源不匹配”的错误，" 跨域"也就以此由来。

　　利用 CORS，http://www.test2.com 只需添加一个标头，就能够容许来自 http://www.test1.com 的请求，下图是我在PHP中的 hander() 设置， “*”号表示容许任何域向咱们的服务端提交请求：

     

　　也能够设置指定的域名，如域名 http://www.test2.com ，那么就容许来自这个域名的请求：

     

     

　　当前我设置的header为“*”，任意一个请求过来以后服务端咱们均可以进行处理&响应，那么在调试工具中能够看到其头信息设置，其中见红框中有一项信息是“ Access-Control-Allow-Origin：* ”，表示咱们已经启用CORS，以下图。

　　PS：因为demo都在我厂的两台测试机间完成，外网也不能访问，因此在这就不提供demo了，见谅

     

 　　简单的一个header设置，一个支持跨域&POST请求的server就完成了:)

 

　　固然，若是没有开启CORS一定失败的啦，以下图：

　　

问题&小结

• 刚刚说到的兼容性。CORS是W3C中一项较新的方案，因此部分浏览器尚未对其进行支持或者完美支持，详情可移至 http://www.w3.org/TR/cors/
• 安全问题。CORS提供了一种跨域请求方案，但没有为安全访问提供足够的保障机制，若是你须要信息的绝对安全，不要依赖CORS当中的权限制度，应当使用更多其它的措施来保障，好比OAuth2。

 

　　自认为的cors使用场景：

• cors在移动终端支持的不错，能够考虑在移动端全面尝试；PC上有不兼容和没有完美支持，因此当心踩坑。固然浏览器兼容就是个伪命题，说不许某个浏览器的某个版本就完美兼容了，说不许就有点小坑，尼玛伤不起！～
• jsonp是get形式，承载的信息量有限，因此信息量较大时CORS是不二选择；
• 配合新的JSAPI(fileapi、xhr2等)一块儿使用，实现强大的新体验功能。

http://www.cnblogs.com/Darren_code/p/cors.html

 

一，简单跨域（不带头 不带参数）
要在servlet的doget或者dopost里增长返回头
resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com"); 若是是公共的则返回*便可。
二，复杂跨域
浏览器会先发起一个验证的网络链接到servlet的 doOptions 在doOptions里返回
resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com");
resp.addHeader("Access-Control-Allow-Methods","GET,POST,OPTIONS");
resp.addHeader("Access-Control-Allow-Headers", "Content-type,hello");

resp.addHeader("Access-Control-Max-Age", "50");便可
三，post传参 加这句话
xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
四，get传参 直接加在url里
五，servelet接受参数
直接调用req.getparams...

http://yunshangbuhe.iteye.com/blog/1979587

 

 

本文概述了跨域资源共享机制及其所涉及的 HTTP 首部字段。

概述EDIT

跨域资源共享标准新增了一组 HTTP 首部字段，容许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生反作用的 HTTP 请求方法（特别是 GET 之外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否容许该跨域请求。服务器确认容许以后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也能够通知客户端，是否须要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

接下来的内容将讨论相关场景，并剖析该机制所涉及的 HTTP 首部字段。

若干访问控制场景EDIT

这里，咱们使用三个场景来解释跨域资源共享机制的工做原理。这些例子都使用 XMLHttpRequest 对象。

本文中的 JavaScript 代码片断均可以从 http://arunranga.com/examples/access-control/ 得到。另外，使用支持跨域  XMLHttpRequest 的浏览器访问该地址，能够看到代码的实际运行结果。

关于服务端对跨域资源共享的支持的讨论，请参见这篇文章： Server-Side_Access_Control (CORS)。

简单请求

某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，请注意，该术语并不属于 Fetch （其中定义了 CORS）规范。若请求知足全部下述条件，则该请求可视为“简单请求”：

• 使用下列方法之一：
  • GET
  • HEAD
  • POST
• Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合以外的其余首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （须要注意额外的限制）
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
•  Content-Type 的值属于下列之一：
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

注意: 这些跨域请求与浏览器发出的其余跨域请求并没有二致。若是服务器未返回正确的响应首部，则请求方不会收到任何数据。所以，那些不容许跨域请求的网站无需为这一新的 HTTP 访问控制特性担忧。

注意: WebKit Nightly 和 Safari Technology Preview 为 Accept,  Accept-Language, 和  Content-Language 首部字段的值添加了额外的限制。若是这些首部字段的值是“非标准”的，WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并无在文档中列出哪些值是“非标准”的，不过咱们能够在这里找到相关讨论： Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language,  Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and  Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它浏览器并不支持这些额外的限制，由于它们不属于规范的一部分。

好比说，假如站点 http://foo.example 的网页应用想要访问 http://bar.other 的资源。http://foo.example 的网页中可能包含相似于下面的 JavaScript 代码：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';
   
function callOtherDomain() {
  if(invocation) {    
    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

客户端和服务器之间使用 CORS 首部字段来处理跨域权限：

分别检视请求报文和响应报文：

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

第 1~10 行是请求首部。第10行 的请求首部字段 Origin 代表该请求来源于 http://foo.exmaple。

第 13~22 行是来自于 http://bar.other 的服务端响应。
响应中携带了响应首部字段 Access-Control-Allow-Origin（第 16 行）。
使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。
本例中，服务端返回的 Access-Control-Allow-Origin: * 代表，该资源能够被任意外域访问。
若是服务端仅容许来自 http://foo.example 的访问，该首部字段的内容以下：

Access-Control-Allow-Origin: http://foo.example

如今，除了 http://foo.example，其它外域均不能访问该资源（该策略由请求首部中的 ORIGIN 字段定义，见第10行）。
Access-Control-Allow-Origin 应当为 * 或者包含由 Origin 首部字段所指明的域名。

预检请求

与前述简单请求不一样，“需预检的请求”要求必须首先使用 OPTIONS   方法发起一个预检请求到服务器，以获知服务器是否容许该实际请求。"预检请求“的使用，能够避免跨域请求对服务器的用户数据产生未预期的影响。

当请求知足下述任一条件时，即应首先发送预检请求：

• 使用了下面任一 HTTP 方法：
  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH
• 人为设置了对 CORS 安全的首部字段集合以外的其余首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but note the additional requirements below)
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
•  Content-Type 的值不属于下列之一:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

注意: WebKit Nightly 和 Safari Technology Preview 为Accept, Accept-Language, 和 Content-Language 首部字段的值添加了额外的限制。若是这些首部字段的值是“非标准”的，WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并无在文档中列出哪些值是“非标准”的，不过咱们能够在这里找到相关讨论：Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它浏览器并不支持这些额外的限制，由于它们不属于规范的一部分。

以下是一个须要执行预检请求的 HTTP 请求：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
    
function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

 

上面的代码使用 POST 请求发送一个 XML 文档，该请求包含了一个自定义的请求首部字段（X-PINGOTHER: pingpong）。另外，该请求的 Content-Type 为 application/xml。所以，该请求须要首先发起“预检请求”。

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

预检请求完成以后，发送实际请求：

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

浏览器检测到，从 JavaScript 中发起的请求须要被预检。从上面的报文中，咱们看到，第 1~12 行发送了一个使用 OPTIONS 方法的“预检请求”。 OPTIONS 是 HTTP/1.1 协议中定义的方法，用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段：

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER

首部字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。服务器据此决定，该实际请求是否被容许。

第14~26 行为预检请求的响应，代表服务器将接受后续的实际请求。重点看第 17~20 行：

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

首部字段 Access-Control-Allow-Methods 代表服务器容许客户端使用 POST, GET 和 OPTIONS 方法发起请求。该字段与 HTTP/1.1 Allow: response header 相似，但仅限于在须要访问控制的场景中使用。

首部字段 Access-Control-Allow-Headers 代表服务器容许请求中携带字段 X-PINGOTHER 与 Content-Type。与 Access-Control-Allow-Methods 同样，Access-Control-Allow-Headers 的值为逗号分割的列表。

最后，首部字段 Access-Control-Max-Age 代表该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，若是该首部字段的值超过了最大有效时间，将不会生效。

预检请求与重定向

大多数浏览器不支持针对于预检请求的重定向。若是一个预检请求发生了重定向，浏览器将报告错误：

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirect

CORS 最初要求该行为，不过在后续的修订中废弃了这一要求。

在浏览器的实现跟上规范以前，有两种方式规避上述报错行为：

• 在服务端去掉对预检请求的重定向；
• 将实际请求变成一个简单请求。

若是上面两种方式难以作到，咱们仍有其余办法：

• 使用简单请求模拟预检请求，用以探查预检请求是否重定向到其余 URL（使用  Response.url 或 XHR.responseURL）；
• 向上一步中得到的 URL 发起请求。

不过，若是请求因为缺失 Authorization 字段而引发一个预检请求，则这一方法将没法使用。这种状况只能由服务端进行更改。

附带身份凭证的请求

Fetch 与 CORS 的一个有趣的特性是，能够基于  HTTP cookies 和 HTTP 认证信息发送身份凭证。通常而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。若是要发送凭证信息，须要设置 XMLHttpRequest 的某个特殊标志位。

本例中，http://foo.example 的某脚本向 http://bar.other 发起一个GET 请求，并设置 Cookies：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

第 7 行将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。由于这是一个简单 GET 请求，因此浏览器不会对其发起“预检请求”。可是，若是服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。

客户端与服务器端交互示例以下：

GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]

即便第 11 行指定了 Cookie 的相关信息，可是，若是 bar.other 的响应中缺失 Access-Control-Allow-Credentials: true（第 19 行），则响应内容不会返回给请求的发起者。

附带身份凭证的请求与通配符

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“*”。

这是由于请求的首部中携带了 Cookie 信息，若是 Access-Control-Allow-Origin 的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。若是操做失败，将会抛出异常。

HTTP 响应首部字段EDIT

本节列出了规范所定义的响应首部字段。上一小节中，咱们已经看到了这些首部字段在实际场景中是如何工做的。

Access-Control-Allow-Origin

响应首部中能够携带一个 Access-Control-Allow-Origin 字段，其语法以下:

Access-Control-Allow-Origin: <origin> | *

其中，origin 参数的值指定了容许访问该资源的外域 URI。对于不须要携带身份凭证的请求，服务器能够指定该字段的值为通配符，表示容许来自全部域的请求。

例如，下面的字段值将容许来自 http://mozilla.com 的请求：

Access-Control-Allow-Origin: http://mozilla.com

若是服务端指定了具体的域名而非“*”，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不一样的源站返回不一样的内容。

Access-Control-Expose-Headers

Access-Control-Expose-Headers 首部字段指定了服务端容许的首部字段集合。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

服务器容许请求中携带 X-My-Custom-Header 和 X-Another-Custom-Header 这两个字段。

Access-Control-Max-Age

Access-Control-Max-Age 首部字段指明了预检请求的响应的有效时间。

Access-Control-Max-Age: <delta-seconds>

delta-seconds 表示该响应在多少秒内有效。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 首部字段用于预检请求的响应，代表服务器是否容许 credentials 标志设置为 true 的请求。请注意：简单 GET 请求不会被预检；若是对此类请求的响应中不包含该字段，浏览器不会将响应返回给请求的调用者。

Access-Control-Allow-Credentials: true

上文已经讨论了附带身份凭证的请求。

Access-Control-Allow-Methods

Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所容许使用的 HTTP 方法。

Access-Control-Allow-Methods: <method>[, <method>]*

相关示例见这里。

Access-Control-Allow-Headers

Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中容许携带的首部字段。

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

HTTP 请求首部字段EDIT

本节列出了可用于发起跨域请求的首部字段。请注意，这些首部字段无须手动设置。 当开发者使用 XMLHttpRequest 对象发起跨域请求时，它们已经被设置就绪。

Origin

Origin 首部字段代表预检请求或实际请求的源站。

Origin: <origin>

origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

Note: 有时候将该字段的值设置为空字符串是有用的，例如，当源站是一个 data URL 时。

注意，无论是否为跨域请求，ORIGIN 字段老是被发送。

Access-Control-Request-Method

Access-Control-Request-Method 首部字段用于预检请求。其做用是，将实际请求所使用的 HTTP 方法告诉服务器。

Access-Control-Request-Method: <method>

相关示例见这里。

Access-Control-Request-Headers

Access-Control-Request-Headers 首部字段用于预检请求。其做用是，将实际请求所携带的首部字段告诉服务器。

Access-Control-Request-Headers: <field-name>[, <field-name>]*

相关示例见这里。

规范EDIT

Specification	Status	Comment
Fetch CORS	Living Standard	New definition; supplants CORS specification.
CORS	Recommendation	Initial definition.

浏览器兼容性EDIT

 

• Desktop
 
• Mobile

Feature	Chrome	Firefox (Gecko)	Internet Explorer	Opera	Safari
Basic support	4	3.5	8 (via XDomainRequest) 10	12	4

 

注：

• IE 10 提供了对规范的完整支持，但在较早版本（8 和 9）中，CORS 机制是借由 XDomainRequest 对象完成的。
• Firefox 3.5 引入了对 XMLHttpRequests 和 Web 字体的跨域支持（但最初的实现并不完整，这在后续版本中获得完善）；Firefox 7 引入了对 WebGL 贴图的跨域支持；Firefox 9 引入了对 drawImage 的跨域支持。

参见EDIT

• Code Samples Showing XMLHttpRequest and Cross-Origin Resource Sharing
• Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)
• Cross-Origin Resource Sharing specification
• XMLHttpRequest
• Fetch API
• Using CORS with All (Modern) Browsers
• Using CORS - HTML5 Rocks

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

 

什么是CORS?

Cross-origin resource sharing(跨域资源共享),是一个W3C标准,它容许你向一个不一样源的服务器发出XMLHttpRequest请求,从而克服了ajax只能请求同源服务的限制.而且也能够经过灵活的设置,来指定什么样的请求是能够被受权的.

什么是跨域?

假设你在http://xxx.com/test/下有一个js文件,从这个js里发出一个ajax请求请求后端服务,按照以下状况断定:

请求地址	缘由	结果
http://xxx.com/xxxx/action	同一域名,不一样文件夹	非跨域
http://xxx.com/test/action	同一域名,同一文件夹	非跨域
http://a.xxx.com/test/action	不一样域名,文件路径相同	跨域
http://xxx.com:8080/test/action	同一域名,不一样端口	跨域
https://xxx.com/test/action	同一域名,不一样协议	跨域

还有那些其余的跨域解决方案?

• JSONP : 动态添加一个<script>标签，而script标签的src属性是没有跨域的限制的。这样说来，这种跨域方式其实与ajax XmlHttpRequest协议无关了,而缺点也很明显,它只支持GET请求而不支持POST等其它类型的HTTP请求；它只支持跨域HTTP请求这种状况，不能解决不一样域的两个页面之间如何进行JavaScript调用的问题

• NGINX代理 : 经过一个代理服务器,将跨域的请求转发,如:前端JS在http://www.demo.com/a.js,后端是http://www.abc.com/app/action,经过代理可将后端的地址转换成http://www.demo/app/action,这样,从前端发起的请求,就不存在跨域的状况了

而后CORS是支持全部类型的HTTP请求,而且也只是服务端进行设置便可,可是缺点就是老的浏览器不支持CORS(如:IE7,7,8,等)

思路

CORS的响应头

• Access-Control-Allow-Origin : 必须的,容许的域名,若是设置*,则表示接受任何域名

• Access-Control-Allow-Credentials : 非必须的,表示是否容许发送Cookie,注意,当设置为true的时候,客户端的ajax请求,也须要将withCredentials属性设置为true

• Access-Control-Expose-Headers : 非必须的,表示客户端能拿到的header,默认状况下XMLHttpRequest的getResponseHeader方法只能拿到几个基本的header,若是有自定义的header要获取的话,则须要设置此值

• Access-Control-Request-Method : 必须的,表示CORS上会使用到那些HTTP方法

• Access-Control-Request-Headers : 必须的,表示CORS上会有那些额外的的有信息

CORS将请求分为两种类型

两种类型分别为简单请求和非简单请求,同时知足如下两大条件的请求被定义为是简单请求:

• 请求方法是如下三种之一:

• HEAD

• GET

• POST

• HTTP头信息不超出如下几种字段:

• Accept

• Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

对于非简单请求,浏览器会自动发一个预检请求,这个请求是OPTIONS方法的,主要是询问服务器当前请求是否在容许范围内

实现

1.方式A:使用@CrossOrigin来标记指定的方法(小范围跨域)

@RequestMapping(value = "add", method = RequestMethod.GET) @CrossOrigin(methods = { RequestMethod.GET, RequestMethod.POST }, origins = "*") public RestResponse<Integer> add(Integer a, Integer b) { return new RestResponse<>(demoService.add(a, b)); }

2.方式B:使用spring boot的默认配置来设定全局跨域

endpoints.cors.allow-credentials= endpoints.cors.allowed-headers= endpoints.cors.allowed-methods=GET endpoints.cors.allowed-origins= endpoints.cors.exposed-headers= endpoints.cors.max-age=1800

3.方式C:使用WebMvcConfigurer自定义配置跨域

定义CorsRegistrationConfig类

public static class CorsRegistrationConfig { //描述 : 扫描地址 private String mapping = "/**"; //描述 : 容许证书 private Boolean allowCredentials = null; //描述 : 容许的域 private String allowedOrigins = "*"; //描述 : 容许的方法 private String allowedMethods = "POST,GET,DELETE,PUT"; //描述 : 容许的头信息 private String allowedHeaders = "*"; .........省略 }

定义CorsConfig类

@Configuration @ConfigurationProperties(prefix = "org.itkk.cors") @Validated public class CorsConfig { //描述 : 跨域信息 @NotNull private Map<String, CorsRegistrationConfig> config; .....省略 }

定义重写addCorsMappings方法

@Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurerAdapter() { @Override public void addCorsMappings(CorsRegistry registry) { //扫描地址 if (!CollectionUtils.isEmpty(config)) { Iterator<String> keys = config.keySet().iterator(); while (keys.hasNext()) { String key = keys.next(); CorsRegistrationConfig item = config.get(key); CorsRegistration cr = registry.addMapping(item.getMapping()); if (item.getAllowCredentials() != null) { cr.allowCredentials(item.getAllowCredentials()); } if (StringUtils.isNotBlank(item.getAllowedOrigins())) { String[] allowedOriginArray = item.getAllowedOrigins().split(","); cr.allowedOrigins(allowedOriginArray); } if (StringUtils.isNotBlank(item.getAllowedMethods())) { String[] allowedMethodArray = item.getAllowedMethods().split(","); cr.allowedMethods(allowedMethodArray); } if (StringUtils.isNotBlank(item.getAllowedHeaders())) { String[] allowedHeaderArray = item.getAllowedHeaders().split(","); cr.allowedHeaders(allowedHeaderArray); } } } } }; }

配置文件,可根据不一样的mapping设置不一样的cors规则

org.itkk.cors.config.demo.mapping=/** org.itkk.cors.config.demo.allowCredentials= org.itkk.cors.config.demo.allowedOrigins= org.itkk.cors.config.demo.allowedMethods= org.itkk.cors.config.demo.allowedHeaders=

使用jquery,在跨域场景下进行测试

$(function(){ $.ajax({ url:'http://127.0.0.1:8080/demo/c', headers:{ 'aheader':'111' }, type:'GET', dataType:'json', success:function(data){ console.log(1); console.log(data); console.log(2); } }); });

代码仓库 (博客配套代码)

• udf-starter : 基础项目,脚手架,框架

• udf-sample : 集成样例

结束

演示了单spring boot的应用的,在后续的章节中,会找机会写一下在微服务场景下(spring cloud)的跨域设置

http://www.cnblogs.com/itkk/p/7447118.html

运行时何处会添加responseHeader的Origin？

prehandle:

RequestMapping方法(该方法执行结束后添加)

posthandle

aftercomplish

crossOrigin注解中的method，若是写了会覆盖requestMethod中指定的，不写的话默认就是requestMethod中指定的。

request中默认会设定本身的Origin。

如上连接官方文档所说，只有简单请求才会触发preflight.

因此postman测试本地程序时：

get方法，以及body为空的post,设置的跨域不起做用，request中header的origin为空。就跟没设置同样。 浏览器get也不起做用
body包含了文件的post,设置的跨域起做用。此时request中header的origin不为空，response也不为空。（能够查看本地的origin）

注意maxAge，若是某个地方未能跨域访问，因为其缓存，致使其它原本能跨域访问的也不能访问了。

/** 匹配的是 /开始的全部路径及文件，包括//domain,也包括/domain
/* 匹配的是/开始的，包括/domain,但不包括//domain，也不包括/domain/file

因此若是设置了但不起做用，极可能是如下两个缘由：

全局设定时路径没匹配对
多个路径的状况下有遗漏的路径没有设定，缓存的缘由。

https://blog.csdn.net/yangyi1101/article/details/77307312


Using pre-signed URLs to upload a file to a private S3 bucket

https://sanderknape.com/2017/08/using-pre-signed-urls-upload-file-private-s3-bucket/