获取网页请求状态

2005 年 2 月，AJAX 这个词第一次正式提出，它是 Asynchronous JavaScript and XML 的缩写，指的是通过 JavaScript 的 异步通信，从服务器获取 XML 文档从中提取数据，再更新当前网页的对应部分，而不用刷新整个网页。 具体来说，AJAX 包括以下几个步骤。 1.创建 XMLHttpRequest 对象，也就是创建一个异步调用对象 2.创建一个新的 HTTP 请求，并指定该 HTTP 请求的方法、URL 及验证信息 3.设置响应 HTTP 请求状态变化的函数 4.发送 HTTP 请求 5.获取异步调用返回的数据 6.使用 JavaScript 和 DOM 实现局部刷新 const SERVER_URL = "/server"; let xhr = new XMLHttpRequest(); // 创建 Http 请求 xhr.open("GET", SERVER_URL, true); // 设置状态监听函数 xhr.onreadystatechange = function() { if (this.readyState !== 4) return; // 当请求成功时 if (this.status === 200) { handle(this.response); } else { console.error(this.statusText); } }; // 设置请求失败时的监听函数 xhr.onerror = function() { console.error(this.statusText); }; // 设置请求头信息 xhr.responseType = "json"; xhr.setRequestHeader("Accept", "application/json"); // 发送 Http 请求 xhr.send(null); // promise 封装实现： function getJSON(url) { // 创建一个 promise 对象 let promise = new Promise(function(resolve, reject) { let xhr = new XMLHttpRequest(); // 新建一个 http 请求 xhr.open("GET", url, true); // 设置状态的监听函数 xhr.onreadystatechange = function() { if (this.readyState !== 4) return; // 当请求成功或失败时，改变 promise 的状态 if (this.status === 200) { resolve(this.response); } else { reject(new Error(this.statusText)); } }; // 设置错误监听函数 xhr.onerror = function() { reject(new Error(this.statusText)); }; // 设置响应的数据类型 xhr.responseType = "json"; // 设置请求头信息 xhr.setRequestHeader("Accept", "application/json"); // 发送 http 请求 xhr.send(null); }); return promise; }

请求错误 这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。 如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。 400 Bad Request 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。 401 Unauthorized 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 402 Payment Required 该状态码是为了将来可能的需求而预留的。 403 Forbidden 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。 404 Not Found 请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。 405 Method Not Allowed 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。 406 Not Acceptable 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。 407 Proxy Authentication Required 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。 408 Request Timeout 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 409 Conflict 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。 410 Gone 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。 411 Length Required 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。 412 Precondition Failed 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。 413 Request Entity Too Large 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。 414 Request-URI Too Long 请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括： 本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。 重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。 415 Unsupported Media Type 对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。 416 Requested Range Not Satisfiable 如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。 417 Expectation Failed 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。 421 too many connections There are too many connections from your internet address 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 422 Unprocessable Entity 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV） 423 Locked 当前资源被锁定。（RFC 4918 WebDAV） 424 Failed Dependency 由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV） 425 Unordered Collection 在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。 426 Upgrade Required 客户端应当切换到TLS/1.0。（RFC 2817） 449 Retry With 由微软扩展，代表请求应当在执行完适当的操作后进行重试。 451Unavailable For Legal Reasons 该请求因法律原因不可用。（RFC 7725）

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

详细解答可以参考官方帮助文档 同源策略 跨域访问，或者说 JavaScript 的跨域访问问题，是浏览器出于安全考虑而设置的一个限制，即同源策略。举例说明，当 A，B 两个网站属于不同的域时，如果来自于 A 网站的页面中的 JavaScript 代码希望访问 B 网站的时候，浏览器会拒绝该访问。 然而，在实际应用中，经常会有跨域访问的需求。比如用户的网站 www.a.com，后端使用了 OSS，在网页中提供了使用 JavaScript 实现的上传功能，但是在该页面中，只能向 www.a.com 发送请求，向其他网站发送的请求都会被浏览器拒绝。这样会导致用户上传的数据必须从www.a.com 中转。如果设置了跨域访问的话，用户就可以直接上传到 OSS 而无需从 www.a.com 中转。 CORS 介绍 跨域资源共享（Cross-Origin Resource Sharing，简称 CORS），是 HTML5 提供的标准跨域解决方案，具体的CORS规则可以参考W3C CORS规范。 CORS 是一个由浏览器共同遵循的一套控制策略，通过HTTP的Header来进行交互。浏览器在识别到发起的请求是跨域请求的时候，会将Origin的Header加入HTTP请求发送给服务器，比如上面那个例子，Origin的Header就是www.a.com。服务器端接收到这个请求之后，会根据一定的规则判断是否允许该来源域的请求，如果允许的话，服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header，内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求的话，将Access-Control-Allow-Origin的Header设置为*即可，浏览器根据是否返回了对应的Header来决定该跨域请求是否成功，如果没有附加对应的Header，浏览器将会拦截该请求。 以上描述的仅仅是简单情况，CORS规范将请求分为两种类型，一种是简单请求，另外一种是带预检的请求。预检机制是一种保护机制，防止资源被本来没有权限的请求修改。浏览器会在发送实际请求之前先发送一个OPTIONS的HTTP请求来判断服务器是否能接受该跨域请求。如果不能接受的话，浏览器会直接阻止接下来实际请求的发生。 只有同时满足以下两个条件才不需要发送预检请求： 请求方法是如下之一： GET HEAD POST 所有的Header都在如下列表中： Cache-Control Content-Language Content-Type Expires Last-Modified Pragma 预检请求会附带一些关于接下来的请求的信息给服务器，主要有以下几种： Origin：请求的源域信息 Access-Control-Request-Method：接下来的请求类型，如POST、GET等 Access-Control-Request-Headers：接下来的请求中包含的用户显式设置的Header列表 服务器端收到请求之后，会根据附带的信息来判断是否允许该跨域请求，信息返回同样是通过Header完成的： Access-Control-Allow-Origin：允许跨域的Origin列表 Access-Control-Allow-Methods：允许跨域的方法列表 Access-Control-Allow-Headers：允许跨域的Header列表 Access-Control-Expose-Headers：允许暴露给JavaScript代码的Header列表 Access-Control-Max-Age：最大的浏览器缓存时间，单位为s 浏览器会根据以上的返回信息综合判断是否继续发送实际请求。当然，如果没有这些Header浏览器会直接阻止接下来的请求。 说明 这里需要再次强调的一点是，以上行为都是浏览器自动完成的，用户无需关注这些细节。如果服务器配置正确，那么和正常非跨域请求是一样的。 CORS主要使用场景 CORS使用一定是在使用浏览器的情况下，因为控制访问权限的是浏览器而非服务器。因此使用其它的客户端的时候无需关心任何跨域问题。 使用CORS的主要应用就是在浏览器端使用Ajax直接访问OSS的数据，而无需走用户本身的应用服务器中转。无论上传或者下载。对于同时使用OSS和使用Ajax技术的网站来说，都建议使用CORS来实现与OSS的直接通信。 OSS对CORS的支持 OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考PutBucketCORS。 CORS请求的通过与否和OSS的身份验证等是完全独立的，即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候，如果www.a.com的请求先到达服务器，服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求，浏览器会将Cache的上一次请求返回给用户，这个时候Header的内容和CORS的要求不匹配，就会导致后面的请求失败。 说明 目前OSS的所有Object相关的接口都提供了CORS相关的验证，另外Multipart相关的接口目前也已经完全支持CORS验证。 GET请求跨域示例 这里举一个使用Ajax从OSS获取数据的例子。为了简单起见，使用的Bucket都是public，访问私有的Bucket的CORS配置是完全一样的，只需要在请求中附加签名即可。 简单开始 首先创建一个Bucket，这里举例为oss-cors-test，将权限设置为public-read，然后这里创建一个test.txt的文本文档，上传到这个Bucket。 单击此处，获取test.txt的访问地址。 说明 请将下文中的地址换成自己试验的地址。 首先用curl直接访问： curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt just for test 可见现在已经能正常访问了。 那么我们现在再试着使用Ajax技术来直接访问这个网站。我们写一个最简单的访问的HTML，可以将以下代码复制到本地保存成html文件然后使用浏览器打开。因为没有设置自定义的头，因此这个请求是不需要预检的。 <!DOCTYPE html> <html> <head> <script type="text/javascript" src="./functions.js"></script> </head> <body> <script type="text/javascript"> // Create the XHR object. function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if ("withCredentials" in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest != "undefined") { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr; } // Make the actual CORS request. function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = 'http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt'; var xhr = createCORSRequest('GET', url); if (!xhr) { alert('CORS not supported'); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert('Response from CORS request to ' + url + ': ' + title); }; xhr.onerror = function() { alert('Woops, there was an error making the request.'); }; xhr.send(); } </script> <p align="center" style="font-size: 20px;"> <a href="#" onclick="makeCorsRequest(); return false;">Run Sample</a> </p> </body> </html> 打开文件后点击链接（以Chrome为例），提示该链接无法访问。 利用Chrome的开发者工具来查看错误原因。 这里告诉我们是因为没有找到Access-Control-Allow-Origin这个头。显然，这就是因为服务器没有配置CORS。 再进入Header界面，可见浏览器发送了带Origin的Request，因此是一个跨域请求，在Chrome上因为是本地文件所以Origin是null。 设置 Bucket CORS知道了上文的问题，那么现在可以设置Bucket相关的CORS来使上文的例子能够执行成功。为了直观起见，这里使用控制台来完成CORS的设置。如果用户的CORS设置不是很复杂，也建议使用控制台来完成CORS设置。CORS设置的界面如下： CORS设置是由一条一条规则组成的，真正匹配的时候会从第一条开始逐条匹配，以最早匹配上的规则为准。现在添加第一条规则，使用最宽松的配置： 这里表示的意思就是所有的Origin都允许访问，所有的请求类型都允许访问，所有的Header都允许，最大的缓存时间为1s。 配置完成之后重新测试，结果如下： 可见现在已经可以正常访问请求了。 因此排查问题来说，如果想要排除跨域带来的访问问题，可以将CORS设置为上面这种配置。这种配置是允许所有的跨域请求的一种配置，因此如果这种配置下依然出错，那么就表明错误出现在其他的部分而不是CORS。 除了最宽松的配置之外，还可以配置更精细的控制机制来实现针对性的控制。比如对于这个场景可以使用如下最小的配置匹配成功： 因此对于大部分场景来说，用户最好根据自己的使用场景来使用最小的配置以保证安全性。 利用跨域实现POST上传 这里提供一个更复杂的例子，这里使用了带签名的POST请求，而且需要发送预检请求。详情请参见PostObjectSample。 说明 将上面的代码下载下来之后，将以下对应的部分全部修改成自己对应的内容，然后使用自己的服务器运行起来。 这里继续使用上文oss-cors-test这个Bucket来进行测试，在测试之前先删除所有的CORS相关的规则，恢复初始状态。 访问这个网页，选择一个文件上传。 同样打开开发者工具，可以看到以下内容，根据上面的Get的例子，很容易明白同样发生了跨域的错误。不过这里与Get请求的区别在于这是一个带预检的请求，所以可以从图中看到是OPTIONS的Response没有携带CORS相关的Header然后失败了。 那么我们根据对应的信息修改Bucket的CORS配置： 再重新运行，可见已经成功了，从控制台中也可以看到新上传的文件。 测试一下内容： $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txt post object test CORS配置的一些注意事项 CORS配置一共有以下几项： 来源：配置的时候要带上完整的域信息，比如示例中 http://10.101.172.96:8001. 注意不要遗漏了协议名如http，如果端口号不是默认的还要带上端口号之类的。如果不确定的话，可以打开浏览器的调试功能查看Origin头。这一项支持使用通配符*，但是只支持一个，可以根据实际需要灵活配置。 Method：按照需求开通对应的方法即可。 Allow Header：允许通过的Header列表，因为这里容易遗漏Header，因此建议没有特殊需求的情况下设置为*。大小写不敏感。 Expose Header：暴露给浏览器的Header列表，不允许使用通配符。具体的配置需要根据应用的需求来选择，只暴露需要使用的Header，如ETag等。如果不需要暴露这些信息，这里可以不填。如果有特殊需求可以单独指定，大小写不敏感。 缓存时间：如果没有特殊情况可以酌情设置的大一点，比如60s。 因此，CORS的一般配置方法就是针对每个可能的访问来源单独配置规则，尽量不要将多个来源混在一个规则中，多个规则之间最好不要有覆盖冲突。其他的权限只开放需要的权限即可。 一些错误排查经验 在调试类似程序的时候，很容易发生一种情况就是将其他错误和CORS错误弄混淆了。 举个例子，当用户因为签名错误访问被拒绝的时候，因为权限验证发生在CORS验证之前，因此返回的结果中并没有带上CORS的Header信息，有些浏览器就会直接报CORS出错，但是实际服务器端的CORS配置是正确的。对于这种情况，我们有两种方式： 查看HTTP请求的返回值，因为CORS验证是一个独立的验证，并不影响主干流程，因此像403之类的返回值不可能是由CORS导致的，需要先排除程序原因。如果之前发送了预检请求，那么可以查看预检请求的结果，如果预检请求中返回了正确的CORS相关的Header，那么表示真实请求应该是被服务器端所允许的，因此错误只可能出现在其他的方面。 将服务器端的CORS设置按照如上文所示，改成允许所有来源所有类型的请求都通过的配置，再重新验证。如果还是验证失败，表明有其他的错误发生。

1、HTTP请求(Request)报文，报文格式为：请求行 – HTTP头(通用信息头，请求头，实体头) – 请求报文主体(只有POST才有报文主体)，如下图 HTTP响应(Response)报文，报文格式为：状态行 – HTTP头(通用信息头，响应头，实体头) – 响应报文主体，如下图 注：通用信息头指的是请求和响应报文都支持的头域， 分别为Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via；实体头则是实体信息的实体头域，分别为Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。这里只是为了方便理解，将通用信息头，响应头/请求头，实体头都归为了HTTP头。 二、缓存过程分析 浏览器与服务器通信的方式为应答模式，即是：浏览器发起HTTP请求 – 服务器响应该请求。那么浏览器第一次向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图： 由上图我们可以知道 1、浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识 2、浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中 以上两点结论就是浏览器缓存机制的关键，他确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了，本文也将围绕着这点进行详细分析。 为了方便大家理解，这里我们根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分，分别是强制缓存和协商缓存 。 2.1强制缓存 强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程，强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下： （1）不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致），如下图： （2）存在该缓存结果和缓存标识，但是结果已经失效，强制缓存失效，则使用协商缓存（暂不分析），如下图 （3）存在该缓存结果和缓存标识，且该结果没有还没有失效，强制缓存生效，直接返回该结果，如下图： 那么强制缓存的缓存规则是什么？ 答：当浏览器向服务器发送请求的时候，服务器会将缓存规则放入HTTP响应的报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Conctrol的优先级比Expires高。 2.1.1Expires Expires是HTTP/1.0控制网页缓存的字段，其值为服务器返回该请求的结果缓存的到期时间，即再次发送请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。 Expires是HTTP/1.0的字段，但是现在浏览器的默认使用的是HTTP/1.1，那么在HTTP/1.1中网页缓存还是否由Expires控制？ 到了HTTP/1.1，Expires已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，如果客户端与服务端的时间由于某些原因（时区不同；客户端和服务端有一方的时间不准确）发生误差，那么强制缓存直接失效，那么强制缓存存在的意义就毫无意义。、 那么Cache-Control又是如何进行控制的？ 2.1.2Cache-Control 在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存，主要取值为： （1）public：所有内容都将被缓存（客户端和代理服务器都可缓存） （2）private：所有内容只有客户端可以缓存，Cache-Control的默认取值 （3）no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定 （4）no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存 （5）max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效 接下来，我们直接看一个例子，如下： 由上面的例子我们可以知道： （1）HTTP响应报文中expires的时间值，是一个绝对值 （2）HTTP响应报文中Cache-Control为max-age=600，是相对值 由于Cache-Control的优先级比expires，那么直接根据Cache-Control的值进行缓存，意思就是说在600秒内再次发起该请求，则会直接使用缓存结果，强制缓存生效。 注：在无法确定客户端的时间是否与服务端的时间同步的情况下，Cache-Control相比于expires是更好的选择，所以同时存在时，只有Cache-Control生效。 了解强制缓存的过程后，我们拓展性的思考一下： 浏览器的缓存存放在哪里，如何在浏览器中判断强制缓存是否生效？ 这里我们以博客的请求为例，状态码为灰色的请求则代表使用了强制缓存，请求对应的Size值则代表该缓存存放的位置，分别为from memory cache 和 from disk cache。 那么from memory cache 和 from disk cache又分别代表的是什么呢？什么时候会使用from disk cache，什么时候会使用from memory cache呢？ from memory cache代表使用内存中的缓存，from disk cache则代表使用的是硬盘中的缓存，浏览器读取缓存的顺序为memory –> disk。 虽然我已经直接把结论说出来了，但是相信有不少人对此不能理解，那么接下来我们一起详细分析一下缓存读取问题，这里仍让以我的博客为例进行分析： 访问https://heyingye.github.io/ –> 200 –> 关闭博客的标签页 –> 重新打开https://heyingye.github.io/ –> 200(from disk cache) –> 刷新 –> 200(from memory cache) 过程如下： （1）访问博客网站 （2）关闭博客的标签页 （3）重新打开博客 （4）刷新 看到这里可能有人小伙伴问了，最后一个步骤刷新的时候，不是同时存在着from disk cache和from memory cache吗？ 对于这个问题，我们需要了解内存缓存(from memory cache)和硬盘缓存(from disk cache)，如下: （1）内存缓存(from memory cache)：内存缓存具有两个特点，分别是快速读取和时效性： 1、快速读取：内存缓存会将编译解析后的文件，直接存入该进程的内存中，占据该进程一定的内存资源，以方便下次运行使用时的快速读取。 2、时效性：一旦该进程关闭，则该进程的内存则会清空。 （2）硬盘缓存(from disk cache)：硬盘缓存则是直接将缓存写入硬盘文件中，读取缓存需要对该缓存存放的硬盘文件进行I/O操作，然后重新解析该缓存内容，读取复杂，速度比内存缓存慢。 在浏览器中，浏览器会在js和图片等文件解析执行后直接存入内存缓存中，那么当刷新页面时只需直接从内存缓存中读取(from memory cache)；而css文件则会存入硬盘文件中，所以每次渲染页面都需要从硬盘读取缓存(from disk cache)。 2.2协商缓存 协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况： （1）协商缓存生效，返回304，如下 （2）协商缓存失败，返回200和请求结果，如下 同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。 2.2.1Last-Modified / If-Modified-Since （1）Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间，如下： （2）If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件，如下。 2.2.2Etag / If-None-Match （1）Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，如下： （2）If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200，如下。 注：Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效。 三、总结 强制缓存优先于协商缓存进行，若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回304，继续使用缓存，主要过程如下： 以上便是浏览器缓存的过程

工单系统的业务流程 " 作为服务于企业和组织的工单系统，其系统内部需要有一套完善的业务流程体系，以满足企业和组织在使用中和操作中的任务分配，事务处理，流程自动化等。下面举个例子来明确该体系所应包含的内容以及一个工单系统流程具体的操作方式：1 一个客户支持职员接到一个电话，或者一个事务提交请求（可能在网页上提交也可能是发送电子邮件），其内容是关于一个具体的问题。一些工单系统提供自动回应和提醒。2 一个服务职员确认该问题的真实性，并通过工单系统或电话收集该客户关于该问题的所有信息。并获取该用户的一些必要信息。3 该服务职员在工单系统中创建该问题，或由客户提交自动在系统自动创建该问题工单，并录入所有关于该问题的相关信息。4 在处理进程中，工单会经历若干状态，直到已解决该问题，工单的内容会随着问题处理的进度而进行相应的更新。并会发送相应的提醒给请求客户。5 当一个工单被解决后，该工单在系统中会被标记成已解决，并作为该客户用户事务的归档以便后续追踪和查阅。从以上简单的流程可以看到，一个优秀的工单系统需要拥有完善的业务流程体系和自定义引擎来方便最终用户和管理人员进行高效的日常操作。

很多网站都需要第一次动态生成,然后一直不变的资源. 这就可以用CND加速. 连这都加速不了的话, CDN还有个鸟用啊..... 只是可能由于是动态资源,第一次获取时有点耗时, 而阿里云之前设定了一个让人蛋疼的CDN请求时间限制, 还不停地重试.  不过通过沟通已解决. ------------------------- 回 6楼(mayle) 的帖子 我说的是第一次生成后下次永久不变的网页...... ------------------------- 回 7楼(licychen) 的帖子 访问拒绝?   是不是OSS有白名单设置却没把CDN域名加进去? ------------------------- 回 10楼(mayle) 的帖子 前面没说对. 内容是永久不变. 但是也许有些模板或显示布局之类的定期改变怎么办? 我说的就是动态界面. 只是保持的状态比较比较持久罢了. 如果是实时修改着数据的系统肯定不需要用CDN.不然也没法让信息实时展示.

通过一个二维码完成多种第三方支付方式支付的需求： 商户打印一个静态的二维码，顾客用app（比如支付宝、微信、百度钱包）扫这个二维码后，进入商户的一个付款页面，输入金额后，完成支付。 其技术实现方式如下： 第一步：生成二维码 通常线下场景是一个门店一个二维码，因此生成二维码时最好加入门店id参数。可以方便使用统一门店编号定位到是哪个商户的交易，结算给哪个商户，收款成功后通知给哪个商户。一般建议生成二维码的url不要太长，长度越短则生成的二维码识别率越高。 第二步：扫码识别 用户扫码时，可能会有许多种软件来扫，但能够处理支付宝交易的却只有支付宝客户端。因此需要做识别扫码来源并在页面作出提示，引导用户用支付宝扫码。用户用app扫商户的二维码后，其实是用app浏览器打开到商户的页面， 商户页面通过识别浏览器header中的user-agent来判断是哪个app打开的。 常见App浏览器的user-agent 识别关键字： 支付宝： AlipayClient 微信： MicroMessenger 如果识别到不包含AlipayClient，则跳转到错误提示页面，引导用户用支付宝扫码。 支付宝扫码成功后，会将门店id提交到你的服务端，你可以存在session中或放在下一步你的授权回调地址参数中。 第三步：获取用户信息 扫码成功后，需要先获取到扫码用户的userid，不然下一步下单无法进行。 获取用户是使用支付宝的用户信息授权实现。 简单来说分为以下五步实现： 拼接你的授权地址，包含授权范围和回调地址 （授权范围用这个scope=auth_base，回调地址中你可以包含一些参数：如门店id）； 让用户浏览器跳转到授权地址，授权后用户浏览器会请求你的redirect_uri回调地址； 授权后你的redirect_uri回调地址会收到auth_code参数； 你使用auth_code参数去换取user_id和access_token (access_token下单接口暂时使用不上，只需要使用user_id值)； 使用access_token可以去获取用户授权信息（这一步开发者一般用不上，授权范围为scope=auth_user时使用，可以获取用户更多信息）； 以上几个步骤可以参考【网页授权获取用户信息】。 拿到user_id后可以给下一步下单使用。 服务端拿到user_id后，user_id可以存session，也可以返回给用户页面隐藏域表单，并给用户页面显示付款页面。 第四步：下单 由于一码多付方案都是最简便方式，没有收银员输入金额的流程。 所以付款页面需要有输入框让用户填写付款金额，并提交表单发起付款。 目前已有了门店id，付款方userid，交易金额，开发者可以通过门店id在你的系统中查到配置的收款方账号信息。此时使用【统一收单交易创建接口】发起下单，下单成功后，支付宝会返回支付宝交易号，使用【JSAPI唤起收银台支付】让用户付款。 服务端将脚本和订单号组装好返回给用户浏览器，用户支付宝浏览器会自动执行js并唤起收银台，让用户选择付款渠道和输入密码，完成付款。 完成付款后，用户页面会跳转到支付宝统一的付款成功页面 第五步：获取收银结果 服务端获取用户的付款状态有两种方式： 1、轮训查询 服务端发起下单后就异步子线程向支付宝发起【交易查询】请求，每隔5秒查一次，查1-2分钟，一旦查到付款成功则终止，如果超时了还未付款，则发起【交易撤销】请求，避免用户在离店之后付款产生单边账纠纷。 2、异步通知 下单时，根据文档在交易创建接口中传递notify_url公共参数，则付款成功后支付宝会给这个notify_url地址发起回调付款结果。 获取异步通知付款结果可以参考【扫码支付异步通知说明】文档。 第六步：通知收银台服务端获取到付款成功的结果后，需要通知收银员（直接让用户拿手机付款结果给收银员看是有风险的，如：用户拿付款成功的截图欺骗收银员，或用户付款成功但商户未入账。）。 最简单的方式是调用短信接口通知这个门店的收银员。如果你之前没有自建短信发送渠道，可以参考使用 阿里大于短信通知方案

1、创建应用 创建应用地址：https://openhome.alipay.com/platform/developerIndex.htm 选择：【创建应用】-【网页&移动应用】-【支付接入】。 注：选择服务商代商户开发，请选择“第三方应用”创建。 第三方应用和自用型应用的区别，详见【第三方应用和自用型应用区别说明】。 第一次入驻显示页面如下，也是选择“支付接入” 2、填写应用名称 2.1、注意命名规范； 2.2、应用类型：网页应用适用于网站，移动应用适用于移动app； 2.3、网址url、应用简介等：可以不用设置； 2.4、Bundle ID、应用签名和应用包名：目前选择移动应用必传，设置成功后即应用中“客户端应用信息”显示信息。获取方式有2种： 方式一： （1）Bundle ID获取详见【客户端应用信息如何配置（iOS版）】 （2）应用签名和应用包名获取详见【客户端应用信息如何配置（Android端）】 方式二： （1）Bundle ID ：在Apple APP Store首页上，点按“我的APP”-选择需要配置的APP查看，把bundle ID 复制填入。 （2）应用签名：查看Android Studio 的最底部选项卡-点开倒数第2个选项卡“Terminal”-输入命令行keytool -list -v -keystore F:\XXXXX.jks（根据实际情况填写）-输入密钥库的口令（.jks文件的password）-把SHA1 复制填写。 注意事项： （1）网页应用和移动应用没有强制要求选择是否设置。 （2）Bundle ID、应用签名和应用包名随意设置是否对app支付有影响？ 目前Bundle ID、应用签名和应用包名只应用于分享到支付宝产品，app支付等产品暂不校验该数据信息，如果可以建议设置正确的数据。 3、修改应用名称、头像等 应用审核上线后，每个月只能修改1次。 4、添加权限功能 （1）点击“添加功能”，勾选添加新功能，点击“确定” 200327-9.png （2）保存，确认添加功能 200327-10.png （3）应用提交审核上线后，状态显示“已上线”，此时可点击“签约”按钮签约。 有关签约方面的疑问请到【商家服务中心】在线咨询或拨打商家服务热线95188咨询。 5、接口加签方式（即设置密钥） 目前接口加签方式支持公钥证书以及普通公钥方式。 注：资金类接口（现金红包、单笔转账到支付宝账户等）必须使用公钥证书，其他接口可使用普通公钥。 （1）公钥证书：详见【如何设置公钥证书】。 （2）普通公钥：详见【如何设置普通公钥】。 加签方式公钥证书修改成公钥详见【公钥证书如何修改成RSA2公钥】。 6、IP白名单 应用中的IP白名单可以不进行设置，后续业务需要，可再添加。 IP白名单作用：为提高商户访问开放平台的安全性，避免商户因应用私钥泄漏等原因导致业务受损，开放平台提供 IP 白名单机制，基于该机制商户可以给 资金操作类敏感接口配置 IP 白名单，开放平台将基于商户配置的 IP 白名单，校验商户请求的来源 IP，若来源 IP 不在配置的 IP 白名单范围内，开放平台将拦截掉对应请求。 IP白名单配置流程：https://docs.open.alipay.com/200/ipwhitelist 7、应用网关、授权回调地址 应用网关是用于接收口碑或是生活号的信息的，授权回调地址是授权时使用的，如不涉及该功能，应用网关和授权回调地址可以不设置。 应用网关和授权回调地址如何配置：具体详见【应用网关和授权回调地址怎么配置】。 注意事项： （1）如调用当面付、手机网站支付、电脑网站支付、app支付等，不涉及以上功能，应用网关和授权回调地址可不设置； （2）应用网关和授权回调地址设置后不涉及以上功能，不影响接口调用； （3）后续开发涉及生活号、口碑、授权等操作时，可再设置应用网关和授权回调地址。 8、接口内容加密方式 接口内容加密方式，即早期的AES密钥设置入口。 注：该数据AES密钥可以不用设置，设置后无法删除，并且设置后如果不使用，不会影响接口调用。 如果需要使用AES密钥加密和解密详见【AES加密说明】。 200428-1.png 9、提交审核 选择“提交审核”按钮。 （1）交易状态变化：开发中-审核中-已上线。 （2）提交审核后，审核时间为1-3个工作日，审核结果不通过需咨询95188。 （3）正式环境接口测试必须在应用为“已上线”状态才可使用，开发中、审核中状态测试报错。 （2）应用状态只有“开发中”才可删除，审核中、已上线状态无法删除应用。 10、代码配置 根据密钥设置的加签方式不同，接口签名方式也不相同 （1）普通公钥签名：详见【普通公钥签名】。 （2）公钥证书签名：详见【公钥证书签名】。 普通公钥和公钥证书签名验签的区别详见【RSA2和公钥证书签名验签的区别】。 注：证书、公钥等都需要从应用的加签方式中下载。

详细解答可以参考官方帮助文档 本文档将帮助你快速开始使用CDN服务，流程如下，请按步骤操作： 步骤一：开通CDN服务 在阿里云官网 CDN产品详情页快速了解产品，之后单击 立即开通。 在购买页面选择适合计费方式，确认订单，CDN服务即开通。接下来就能开始接入您要加速的域名了。 步骤二：添加加速域名 添加域名。 登录CDN控制台，选择域名管理。查看您添加的所有加速域名和状态。点击 添加域名。 填写基本信息。 输入加速域名（一般使用 子域名或泛域名，例如 cdntest.example.com）、选择合适的业务类型、源站。点击 下一步，等待审核。 说明 如果您的源站为阿里云ECS或OSS，则审核速度会加快。 加速域名说明： 支持泛域名加速，不支持中文域名加速，请注意泛域名填写规则如： *.test.com。详细规则请了解泛域名加速规则 加速域名不允许重复添加，如出现域名已添加的提示，请提交工单处理。 每个账户下最多支持20个加速域名，如需扩容请提工单处理。 加速内容需合法、符合CDN业务规范，具体可见 CDN服务使用限制。 业务类型说明： 阿里云CDN调度系统会根据用户选择的不同业务类型做针对性的调度优化： 业务类型 说明 图片小文件 若加速内容多为 小型的静态资源 （如小文件、图片、网页样式文件等），推荐选择“图片小文件”业务类型。 大文件下载 若加速内容为 较大的文档（大于20MB的静态文件），例如游戏安装包、应用更新、手机ROM升级、应用程序包下载等场景，推荐选择大文件下载业务类型。 视音频点播 若大文件为音频或视频 文件，例如音乐、视频的点播业务场景，推荐使用“视音频点播”业务类型。 直播流媒体 提供 直播流媒体 加速服务，目前支持 RTMP 和 HLS 方式的直播加速，直播业务类型不支持自定义源站，目前统一提供直播中心服务器：video-center.alivecdn.com。 全站加速 融合了动态加速和静态加速，适用于动静态内容混合、含较多 动态资源请求的站点。通过简单配置即可智能分别加速动静态内容，静态内容高速缓存，动态内容通过阿里云的最优链路算法及协议层优化快速回源获取。 另有移动加速与安全加速SCDN（CDN 和 高防IP、高度集成的独立产品，具备抗DDoS、抗CC、防刷能力）等业务场景，欢迎提工单咨询或开通。 源站类型说明： 源站类型 说明 IP 支持多个服务器外网 IP， 阿里云ECS的IP可免审核。 源站域名 支持多个源站域名。 说明 源站域名不能与加速域名相同，否则会造成循环解析，无法回源。例如您的源站域名为img.yourdomain.com，则加速域名可设置为cdn.yourdomain.com。 对象存储OSS 可手动输入阿里云OSS Bucket 的外网域名如：xxx.oss-cn-hangzhou.aliyuncs.com，OSS外网域名可前往 OSS控制台 查看。也可直接选择同账号下的 OSS Bucket。 说明 CDN 回源暂不支持 SNI。 加速区域说明： 针对加速业务需求，选择合适的加速区域：中国大陆、海外加速（无国内节点）或 全球加速。 L3以上用户可通过工单申请开通海外加速 海外节点产生的流量费用高于国内流量费用，详见 海外加速费用详情。 如果选择纯海外加速，无需工信部备案。 添加成功。 加速域名审核通过后，会出现在域名管理的域名列表中，状态为正常运行即添加成功： 说明 添加完加速域名后，阿里云CDN会给您分配对应的CNAME地址，还需要配置CNAME后CDN服务才生效。请继续参考下方步骤3。 步骤三：配置CNAME 在控制台域名管理的域名列表中复制加速域名对应的CNAME地址。 前往你的域名解析(DNS)服务商（如万网、阿里云解析、DNSPod、新网、腾讯云解析、route 53、godaddy等），添加该CNAME记录。现提供以下服务商的示例： 万网/阿里云解析与配置CNAME流程 DNSPod 配置CNAME流程 新网 配置CNAME流程 步骤四：验证CDN服务是否生效 配置CNAME后，不同的服务商CNAME生效的时间也不同，一般新增的CNAME记录会立即生效，修改的CNAME记录会需要较长时间生效。 您可以 ping 或 dig 您所添加的加速域名，如果被解析至 *.*kunlun*.com的域名，即表示CNAME配置已经生效，CDN功能也已生效：

详细解答可以参考官方帮助文档 本文档将帮助你快速开始使用CDN服务，流程如下，请按步骤操作： 步骤一：开通CDN服务 在阿里云官网 CDN产品详情页快速了解产品，之后单击 立即开通。 在购买页面选择适合计费方式，确认订单，CDN服务即开通。接下来就能开始接入您要加速的域名了。 步骤二：添加加速域名 添加域名。 登录CDN控制台，选择域名管理。查看您添加的所有加速域名和状态。点击 添加域名。 填写基本信息。 输入加速域名（一般使用 子域名或泛域名，例如 cdntest.example.com）、选择合适的业务类型、源站。点击 下一步，等待审核。 说明 如果您的源站为阿里云ECS或OSS，则审核速度会加快。 加速域名说明： 支持泛域名加速，不支持中文域名加速，请注意泛域名填写规则如： *.test.com。详细规则请了解泛域名加速规则 加速域名不允许重复添加，如出现域名已添加的提示，请提交工单处理。 每个账户下最多支持20个加速域名，如需扩容请提工单处理。 加速内容需合法、符合CDN业务规范，具体可见 CDN服务使用限制。 业务类型说明： 阿里云CDN调度系统会根据用户选择的不同业务类型做针对性的调度优化： 业务类型 说明 图片小文件 若加速内容多为 小型的静态资源 （如小文件、图片、网页样式文件等），推荐选择“图片小文件”业务类型。 大文件下载 若加速内容为 较大的文档（大于20MB的静态文件），例如游戏安装包、应用更新、手机ROM升级、应用程序包下载等场景，推荐选择大文件下载业务类型。 视音频点播 若大文件为音频或视频 文件，例如音乐、视频的点播业务场景，推荐使用“视音频点播”业务类型。 直播流媒体 提供 直播流媒体 加速服务，目前支持 RTMP 和 HLS 方式的直播加速，直播业务类型不支持自定义源站，目前统一提供直播中心服务器：video-center.alivecdn.com。 全站加速 融合了动态加速和静态加速，适用于动静态内容混合、含较多 动态资源请求的站点。通过简单配置即可智能分别加速动静态内容，静态内容高速缓存，动态内容通过阿里云的最优链路算法及协议层优化快速回源获取。 另有移动加速与安全加速SCDN（CDN 和 高防IP、高度集成的独立产品，具备抗DDoS、抗CC、防刷能力）等业务场景，欢迎提工单咨询或开通。 源站类型说明： 源站类型 说明 IP 支持多个服务器外网 IP， 阿里云ECS的IP可免审核。 源站域名 支持多个源站域名。 说明 源站域名不能与加速域名相同，否则会造成循环解析，无法回源。例如您的源站域名为img.yourdomain.com，则加速域名可设置为cdn.yourdomain.com。 对象存储OSS 可手动输入阿里云OSS Bucket 的外网域名如：xxx.oss-cn-hangzhou.aliyuncs.com，OSS外网域名可前往 OSS控制台 查看。也可直接选择同账号下的 OSS Bucket。 说明 CDN 回源暂不支持 SNI。 加速区域说明： 针对加速业务需求，选择合适的加速区域：中国大陆、海外加速（无国内节点）或 全球加速。 L3以上用户可通过工单申请开通海外加速 海外节点产生的流量费用高于国内流量费用，详见 海外加速费用详情。 如果选择纯海外加速，无需工信部备案。 添加成功。 加速域名审核通过后，会出现在域名管理的域名列表中，状态为正常运行即添加成功： 说明 添加完加速域名后，阿里云CDN会给您分配对应的CNAME地址，还需要配置CNAME后CDN服务才生效。请继续参考下方步骤3。 步骤三：配置CNAME 在控制台域名管理的域名列表中复制加速域名对应的CNAME地址。 前往你的域名解析(DNS)服务商（如万网、阿里云解析、DNSPod、新网、腾讯云解析、route 53、godaddy等），添加该CNAME记录。现提供以下服务商的示例： 万网/阿里云解析与配置CNAME流程 DNSPod 配置CNAME流程 新网 配置CNAME流程 步骤四：验证CDN服务是否生效 配置CNAME后，不同的服务商CNAME生效的时间也不同，一般新增的CNAME记录会立即生效，修改的CNAME记录会需要较长时间生效。 您可以 ping 或 dig 您所添加的加速域名，如果被解析至 *.*kunlun*.com的域名，即表示CNAME配置已经生效，CDN功能也已生效：