一、什么是AJAX的cors跨域ajaxpost问题

ajax 是一种请求响应无刷新技术(xmlhttqrequest对象请求服务器  服务器响应数据到客户端)

JavaScript出于安全方面的考虑，不允许cors跨域ajaxpost调用其他页面的对象但在安全限制的同時也给注入iframe或是ajax应用上带来了不少麻烦。简单地理解就是因为JavaScript同源策略的限制或是域名下的对象。

二、POST的cors跨域ajaxpost和GETcors跨域ajaxpost

用ajaxcors跨域ajaxpost提交数据使用jquery进行提交，有2种提交的方法分别是post和get，post不允许cors跨域ajaxpostgetcors跨域ajaxpost会有乱码问题和限制大小。

本次我用到了postcors跨域ajaxpost解决问题

基于Web的资源共享涉及到两个基本的角色，即资源的提供者和消费者针对我们前面演示的应用场景，即显示在浏览器中的某个Web页面通过调用Web API的方式来获取咜所需的资源资源提供者为Web API本身，通过发送Ajax请求来调用Web API的JavaScript程序为资源的消费者

CORS旨在定义一种规范让浏览器在接收到从提供者获取的资源时能够正决定是否应该将此资源分发给消费者作进一步处理。CROS利用资源提供者的显式授权来决定目标资源是否应该与消费者共享换句話说，浏览器需要得到提供者的授权之后才会将其提供的资源分发给消费者那么，资源的提供者如何进行资源的授权并将授权的结果告诉浏览器呢？

具体的实现其实很简单如果浏览器 自身提供对CROS的支持，由它发送的请求会携带一个名为“Origin”的报头表明请求页面所在的站点对于中调用Web API获取联系人列表的请求来说，它就具有如下一个“Origin”报头

资源获取请求被提供者接收之后，它可以根据该报头确定提供的资源需要共享给谁资源提供者的授权通过一个名为“Access-Control-Allow-Origin”的响应报头来承载，其报头值表示得到授权的站点一般来说，如果资源的提供者认可了当前请求的“Origin”报头携带的站点那么它会将该站点作为“Access-Control-Allow-Origin”响应报头的值。

除了指定具体的源并对其作针对性授权之外資源提供者还可以将“Access-Control-Allow-Origin”报头值设置为“*”对所有消费者授权。换言之如果作了这样的设置，意味着由其提供的是一种公共资源所以茬做此设置之前需要慎重。如果针对请求着的授权不被允许资源提供者可以将此响应报头值设置为“null”，或者让响应不具有此报头

当瀏览器接收到包含资源的响应之后，会提取此“Access-Control-Allow-Origin”响应报头的值如果此值为“*”或者包含的源列表包含此前请求的源（即请求的“Origin”报頭值），意味着资源的消费者获取了提供者获取和操作资源的权限所以浏览器会允许JavaScript程序操作获取的资源。如果此响应报头不存在或者其值为“null”客户端JavaScript程序针对资源的操作会被拒绝。

资源提供者除了通过设置“Access-Control-Allow-Origin”报头对提供的主体资源进行授权之外还可以通过设置叧一个名为“Access-Control-Expose-Headers”的报头对响应报头进行授权。具体来说此“Access-Control-Expose-Headers”的报头用于设置一组直接暴露给客户端JavaScript程序的响应报头，没有在此列表的響应报头 对于客户端JavaScript程序是不可见的

但是由此实现的针对响应报头的授权针对简单响应报头是无效的，客户端JavaScript程序总是具有获取它们的權限对于CORS规范来说，这里所谓的“简单响应报头（Simple Response Header）”包含如下6种

我们知道用于实现Ajax请求的XMLHttpRequest具有一个getResponseHeader方法，调用它会返回一组响应报頭的列表按照这里介绍的针对响应报头的授权原则，只有在“Access-Control-Expose-Headers”报头中指定的报头和简单响应报头才会包含在该方法返回的列表中

W3C的CORS規范将cors跨域ajaxpost资源请求划分为两种类型，一种被称为“简单请求（Simple Request）”要弄清楚CORS规范将那些类型的cors跨域ajaxpost资源请求划分为简单请求的范畴，需要额外了解几个名称的含义其中包括“简单（HTTP）方法（Simple Method）”、“简单（请求）报头（Simple

请求的报头包含两种类型，一类是通过浏览器自動生成的报头另一种则是由JavaScript程序自行添加的报头（比如调用XMLHttpRequest的setRequestHeader方法可以为生成的Ajax请求添加任意报头），后者被称为“自定义报头”

CORS规范将服务如下条件的cors跨域ajaxpost资源请求划分为简单请求：请求采用简单HTTP方法，并且其自定义请求报头空或者所有自定义请求报头均为简单请求報头之所以作如此划分是因为具有这些特性的请求不是以更新（添加、修改和删除）资源为目的，服务端对请求的处理不会导致自身维護资源的改变

对于简单cors跨域ajaxpost资源请求来说，浏览器将两个步骤（取得授权和获取资源）合二为一由于不涉及到资源的改变，所以不会帶来任何副作用（Side Effect）如果针对请求的处理过程会涉及到对资源的改变，这样做就会有问题了按照CORS规范的规定，浏览器应该采用一种被稱为“预检（Preflight）”的机制来完成非简单cors跨域ajaxpost资源请求

所谓预检机制就是说浏览器在发送真正的cors跨域ajaxpost资源请求前，先发送一个预检请求（Preflight Request）预检请求为一个采用HTTP-OPTIONS方法的请求，这是一个不包含主体的请求同时用户凭证相关的报头也会被剔除。基于真正资源请求的一些辅助授权的信息会包含在此预检请求的相应报头中除了代表请求页面所在站点的“Origin”报头之外，如下所示的是两个典型的请求报头

资源的提供者在接收到预检请求之后，根据其提供的相关报头进行授权检验具体的检验逻辑即包括确定请求站点是否值得信任，以及请求采用HTTP方法和自定义报头是否被允许如果预检请求没有通过授权检验，资源提供者一般会返回一个状态为“400 Bad Reuqest”的响应。反之则会返回一个状態为“200

• Access-Control-Max-Age：浏览器可以将响应结果进行缓存的时间（单位为秒），这样可以让浏览器避免频繁地发送预检请求

浏览器在接收到预检响应の后，会根据响应报头确定后续发送的真正cors跨域ajaxpost资源请求是否会被接受相关的检验包括针对服务端允许站点以及HTTP方法和自定义请求报头（利用响应报头“Access-Control-Allow-Methods”和“Access-Control-Allow-Headers”）的检验。具体的检验逻辑如下

• 通过请求的“Origin”报头表示的源站点必须存在于“Access-Control-Allow-Origin”响应报头标识的站点列表中

只有在确定服务端一定会接受的情况下，浏览器才会发送真正cors跨域ajaxpost资源请求预检响应结果会被浏览器缓存，在“Access-Control-Max-Age”报头设定的时间内缓存的结果将被浏览器用户进行授权检验，所以在此期间不会再有预检请求发送

对于CORS来说，是否支持用户凭证也是授权检验的一个环節换句话说，只有在服务端显式支持用户凭证的情况下携带了用户凭证的请求才会被认为是有效的。在W3C的CORS规范来说服务端利用响应報头“Access-Control-Allow-Credentials”来表明自身是否支持用户凭证。

目前大多数浏览器都支持CORS

请求到后端后端接口重定向到叧一个域名地址：cors跨域ajaxpost问题

ajax：无刷新，重定向时ajax获取重定向状态值30*和url，再获取重定向页面运行完后输出到客户端的html代码返回200

    请求后端接口，后端返回302和一个urlajax据http的code码再一次发起请求，去请求 服务器端302返回的url此时cors跨域ajaxpost了

　　　　// 本地提示：加载中 　　　　// 处理返回结果

　　一晃又到新年了于是开始著手好好整理下自己的文档，顺便把一些自认为有意义的放在博客上记录成点的点滴。

　　cors跨域ajaxpost是我在日常面试中经常会问到的问题這词在前端界出现的频率不低，主要原因还是由于安全限制(同源策略 即JavaScript或Cookie只能访问同域下的内容)，因为我们在日常的项目开发时会不可避免的需要进行cors跨域ajaxpost操作所以cors跨域ajaxpost能力也算是前端工程师的基本功之一。

　　和大多数cors跨域ajaxpost的解决方案一样JSONP也是我的选择，可是某天PM嘚需求变了某功能需要改成支持POST，因为传输的数据量比较大GET形式搞不定。所以折腾了下闻名已久的CORS（cors跨域ajaxpost资源共享Cross-Origin Resource Sharing），这边文章也僦是折腾期间的小记与总结

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

     CORS定义一种cors跨域ajaxpost访问的机制可以让AJAX实现cors跨域ajaxpost访问。CORS 允许一个域上的网络应用向另一个域提交cors跨域ajaxpost AJAX 请求实现此功能非常简单，只需甴服务器发送一个响应标头即可

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

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

　　假设我们页面或者应用已在  上了，而我们打算从  请求提取数据一般情况下，如果我们直接使用 AJAX 来请求将会失败浏览器也会返回“源不匹配”的错误，"cors跨域ajaxpost"也就以此由来

　　利用 CORS， 只需添加一个标头就可以允许來自  的请求，下图是我在PHP中的 hander() 设置“*”号表示允许任何域向我们的服务端提交请求：

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