前往小程序，Get更优阅读体验！
立即前往
文档建议反馈控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
发布
首页
学习
活动
专区
工具
TVP最新优惠活动
返回腾讯云官网
社区首页 >专栏 >CORS

CORS

原创
作者头像
ruochen
发布于 2021-12-04 10:18:09
3K0
发布于 2021-12-04 10:18:09
举报
文章被收录于专栏：若尘的技术专栏

CORS(https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fzh-

CN%2Fdocs%2FGlossary%2FCORS) 是一个W3C标准，全称是 跨域资源共享 （Cross-Origin Resource

Sharing），也有译为“跨源资源共享”的。

它允许浏览器向跨源服务器，发出

XMLHttpRequest(https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fzh-

CN%2Fdocs%2FWeb%2FAPI%2FXMLHttpRequest)（XHR） 或 [Fetch

API](https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fzh-

CN%2Fdocs%2FWeb%2FAPI%2FFetch_API) 跨域 HTTP

请求，从而克服了同源(https://links.jianshu.com/go?to=http%3A%2F%2Fwww.ruanyifeng.com%2Fblog%2F2016%2F04%2Fsame-

origin-policy.html)使用的限制。

本文内容主要参考于跨域资源共享 CORS 详解和 MDN 相关文档。

一、简介

CORS 是 HTTP 的一部分，它允许服务端来指定哪些主机可以从这个服务端加载资源。

CORS 需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE 浏览器不能低于 IE10。

整个 CORS 通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS 通信与同源的 AJAX 通信没有差别，代码完全一样。浏览器一旦发现

AJAX 请求跨源，就会自动添加一些附件的头信息，有时还会多处一次附件的请求，但用户不会有感觉。

因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口（响应报文包括了正确的 CORS 响应头），就可以跨源通信。

二、同源安全策略

同源策略是一个重要的安全策略，它用于限制一个 Origin 的文档或它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。

**如果两个 URL

的协议(https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fzh-

CN%2Fdocs%2FGlossary%2FProtocol)（Protocol）、主机(https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fzh-

CN%2Fdocs%2FGlossary%2FHost)（Host）、端口(https://links.jianshu.com/go?to=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-

US%2Fdocs%2FGlossary%2FPort)（Port，如果有指定的话）都相同的话，那么这两个 URL 是同源的，否则是不同源的。**

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

URL

结果

原因

http://store.company.com/dir2/other.html

| 同源 | 只有路径不同。

http://store.company.com/dir/inner/another.html

| 同源 | 只有路径不同。

https://store.company.com/secure.html

| 不同源 | 协议不同。

http://store.company.com:81/dir/etc.html

| 不同源 | 端口不同（http:// 默认端口是 80）。

http://news.company.com/dir/other.html

| 不同源 | 主机不同。

关于 IE 浏览器的特例，其中差异点是不规范的，其他浏览器未做出支持。

出于安全性，浏览器限制脚本内发起的跨域 HTTP 请求，例如常见的 XHR、Fetch API 都遵循同源策略。

三、两种请求

浏览器将 CORS 请求分成两类： 简单请求 （simple request）和非简单请求（not-so-simple request）。

若满足下述所有条件，则该请求可视为“简单请求”：

请求方法是以下三种之一：HEAD GET POST HTTP 的头信息不超出以下几种字段：Accept Accept-Language Content-Language Content-Type DPR Downlink Save-Data Viewport-Width Width Content-Type 的值仅限于以下三种之一text/plain multipart/form-data application/x-www-form-urlencoded 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器。 请求中没有使用 ReadableStream 对象。

凡是不同时满足以上条件，均属于非简单请求。

注意: 这些跨站点请求与浏览器发出的其他跨站点请求并无二致。如果服务器未返回正确的响应首部，则请求方不会收到任何数据。因此，那些不允许跨站点请求的网站无需为这一新的 HTTP 访问控制特性担心。

三、简单请求

一个简单的 XHR 请求示例：

客户端（Client）：

代码语言：txt
复制
// Client 客户端（http://192.168.1.105:8080）
代码语言：txt
复制
function xhrRequest() {
代码语言：txt
复制
  // 创建 xhr 对象
代码语言：txt
复制
  const xhr = new XMLHttpRequest()
代码语言：txt
复制
  // 通过 onreadystatechange 事件捕获请求状态的变化
代码语言：txt
复制
  // 必须在 open 之前指定该事件，否则无法接收 readyState 0 和 1 的状态
代码语言：txt
复制
  xhr.onreadystatechange = () => {
代码语言：txt
复制
    console.log(xhr.status)
代码语言：txt
复制
    console.log(xhr.readyState)
代码语言：txt
复制
  }
代码语言：txt
复制
  // 捕获错误
代码语言：txt
复制
  xhr.onerror = err => {
代码语言：txt
复制
    console.log('error:', err)
代码语言：txt
复制
  }
代码语言：txt
复制
  // 初始化请求
代码语言：txt
复制
  xhr.open('GET', 'http://192.168.1.105:7701/config', true)
代码语言：txt
复制
  // 发送请求
代码语言：txt
复制
  xhr.send(null)
代码语言：txt
复制
}
代码语言：txt
复制
xhrRequest()

服务端（Server）：

代码语言：txt
复制
// Server 服务端（通过 node 命令即可启动，http://192.168.1.105:7701）
代码语言：txt
复制
const http = require('http')
代码语言：txt
复制
const port = 7701
代码语言：txt
复制
const allowedOrigin = 'http://192.168.1.105:8080' // 这个是我本地客户端的 Origin（源）
代码语言：txt
复制
const server = http.createServer((request, response) => {
代码语言：txt
复制
  if (request.headers.origin === allowedOrigin) {
代码语言：txt
复制
    response.setHeader('Access-Control-Allow-Origin', allowedOrigin)
代码语言：txt
复制
  }
代码语言：txt
复制
  if (request.url === '/config') {
代码语言：txt
复制
    response.end(JSON.stringify({ name: 'Frankie', age: 20 }))
代码语言：txt
复制
  }
代码语言：txt
复制
})
代码语言：txt
复制
server.listen(port)

发起 XHR HTTP 请求，我们可以在控制台看到请求报文和响应报文。（View source）

1. 基本流程

对于简单请求，浏览器直接发出 CORS 请求。具体来说，就在头信息之中，增加一个 Origin 字段。

通过以上示例发起 HTTP GET 请求，请求报文如下：

代码语言：txt
复制
GET /config HTTP/1.1
代码语言：txt
复制
Host: 192.168.1.105:7701
代码语言：txt
复制
Connection: keep-alive
代码语言：txt
复制
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
代码语言：txt
复制
Accept: */*
代码语言：txt
复制
Origin: http://192.168.1.105:8080
代码语言：txt
复制
Referer: http://192.168.1.105:8080/
代码语言：txt
复制
Accept-Encoding: gzip, deflate
代码语言：txt
复制
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7

上面的头信息中，Origin 字段用来说明，本次请求来自哪个源（协议 + 主机 + 端口）。服务器根据这个值，绝对是否同意这次请求。

如果 Origin 指定的源，不在许可范围内，服务器会返回一个正确的 HTTP 回应。浏览器发现，这个回应的头信息没有包含 `Access-

Control-Allow-Origin字段（相见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror`

回调函数捕获。注意，这种错误无法通过状态识别，因为 HTTP 回应的状态码有可能是 200。

在上述服务端示例中，我们指定的源就是

http://192.168.1.105:8080，因此可以正常发起请求，并拿到接口响应数据：{"name":"Frankie","age":20}。

假设，我们将服务端示例许可的 Origin 去掉：

代码语言：txt
复制
// if (request.headers.origin === allowedOrigin) {
代码语言：txt
复制
//  response.setHeader('Access-Control-Allow-Origin', allowedOrigin)
代码语言：txt
复制
// }

我们再次发起 /config 请求的时候，可以看到控制台抛出跨域错误了：

需要注意的是，尽管无论从控制台看到的报错、还是 Network 选项卡的 Failed to load response data，都可以知道我们的请求失败了。但......其实是这样的： 就本文服务端示例而言，即使是跨域请求，也是会返回响应数据的，只是 JavaScript 脚本获取到的结果是“失败”而已。

那不对啊，如果服务器正常返回数据，而前端却失败了，那信息不对称啊，中间商赚差价了？怎么回事呢？原因是浏览器在中间搞鬼，那浏览器在中间扮演了什么角色呢？

当发起 CORS 请求时，浏览器首先会在请求报文上自动加上 Origin 的字段（它的值由当前页面的 Protocol + Host + Port 部分组成），到达服务端之后，会做出相应的处理并返回数据。由于服务端并没有给响应报文的头部设置 Access-Control-Allow- Origin（前面说把这块注释掉了），自然浏览器接收到的响应报文中就不含 Access-Control-Allow- Origin，当浏览器就判断到请求报文与响应报文的 Origin 不相等，此时它不会将服务器的响应数据 JavaScript 脚本，即我们的 XHR 对象无法得到服务器的响应数据，并且会触发 XHR 对象的 onerror 事件，让脚本来捕获错误。所以，我们就看到请求失败了。（这种情况下，可以通过抓包工具查看服务器返回的数据）

还有，只有在 Origin 指定的源在许可范围内，服务器响应报文才会多出这些 Access-Control-Allow- Origin、Access-Control-Allow-Credentials、Access-Control-Expose-Headers 头信息字段。（可从客户端 Network 选项卡观察到）

以下与 CORS 请求相关的头信息字段，都以 Access-Control- 开头。

代码语言：txt
复制
Access-Control-Allow-Origin: http://10.16.4.226:8080
代码语言：txt
复制
Access-Control-Allow-Credentials: true
代码语言：txt
复制
Access-Control-Expose-Headers: Date
  • Access-Control-Allow-Origin

这个字段是必须的。它的值要么是请求时 Origin 字段的值，要么是一个 *，表示接受任意的源（域名）的请求。

  • Access-Control-Allow-Credentials

这个字段可选。它的值是一个布尔值，表示是否允许发送 Cookie。默认情况下，Cookie 不包括在 CORS 请求之中。设为

true，即表示服务器明确许可，Cookie 可以包含在请求中，一起发给服务器。这个值也只能设为 true，如果服务器不要浏览器发送

Cookie，删除该字段即可。

代码语言：txt
复制
// Client
代码语言：txt
复制
xhr.withCredentials = true
代码语言：txt
复制
// Server
代码语言：txt
复制
response.setHeader('Access-Control-Allow-Credentials', true)

当客户端携带 Cookie 发起请求，同时服务端允许携带 Cookie 的情况下，可以看到请求报文包含了 Cookie 信息：

代码语言：txt
复制
Cookie: username=Frankie
  • Access-Control-Expose-Headers

这个字段可选。CORS 请求时，XMLHttpRequest 对象的 getResponseHeader() 方法只能拿到 6 个基本字段：

Cache-Control、Content-Language、Content-Type、Expires、`Last-

Modified、Pragma。如果想要拿到其他字段，就必须在Access-Control-Expose-Headers` 里面指定。（但由于

W3C 的限制，不指定的情况下，客户端获取到的值可能为 null）

例如，服务端将 Access-Control-Expose-Headers 指定为 `"Date,Access-Control-Allow-

Origin"`，我们可以通过 XMLHttpRequest 对象的 getResponseHeader() 方法获取对应字段的值。

代码语言：txt
复制
// Client
代码语言：txt
复制
xhr.onreadystatechange = () => {
代码语言：txt
复制
  if (xhr.status === 200 && xhr.readyState === 4) {
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Cache-Control')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Content-Language')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Content-Type')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Expires')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Last-Modified')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Pragma')) // null
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Date')) // "Sun, 06 Jun 2021 14:34:34 GMT"
代码语言：txt
复制
    console.log(xhr.getResponseHeader('Access-Control-Allow-Origin')) // "http://192.168.1.105:8080"
代码语言：txt
复制
    console.log(xhr.getResponseHeader('X-Custom-Header')) // Error: Refused to get unsafe header "X-Custom-Header"
代码语言：txt
复制
  }
代码语言：txt
复制
}
代码语言：txt
复制
// Server
代码语言：txt
复制
if (request.headers.origin === allowedOrigin) {
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Origin', allowedOrigin)
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Credentials', true)
代码语言：txt
复制
  response.setHeader('Access-Control-Expose-Headers', 'Date,Access-Control-Allow-Origin')
代码语言：txt
复制
}

如果连接未完成，响应中不存在报文项，或者被 W3C 限制，则返回 null。假设如上示例，自定义头信息 X-Custom-Header 字段，且服务端未对其进行设置，则会抛出错误：Refused to get unsafe header "X-Custom-Header"

2. withCredentials 属性

上面说到，CORS 请求默认不发送 Cookie 和 HTTP 认证信息。如果要把 Cookie 发送到服务器，一方面要服务器同意，指定 `Access-

Control-Allow-Credentials` 字段。

代码语言：txt
复制
Access-Control-Allow-Credentials: true

另一方面，开发者必须在 AJAX 请求中打开 withCredentials 属性。

代码语言：txt
复制
xhr.withCredentials = true

否则，即使服务器同意发送 Cookie，浏览器也不会发送。或者服务器要求设置 Cookie，浏览器也不会处理。

但是，如果省略 withCredentials 设置，有的浏览器还是会一起发送 Cookie。这时，可以显示关闭 withCredentials。

代码语言：txt
复制
xhr.withCredentials = false

需要注意的是，如果要发送 Cookie，Access-Control-Allow-Origin 就不能设为

*（否则会抛出如下错误），必须指定明确的、与请求网页一致的域名。同时，Cookie 依然遵循同源策略，只有用服务器域名设置的 Cookie

才会上传，其他域名的 Cookie 并不会上传，且（跨源）原网页代码中的 document.cookie 也无法读取服务器域名下的 Cookie。

四、非简单请求

调整一下示例：

代码语言：txt
复制
// Client 客户端
代码语言：txt
复制
function xhrRequest() {
代码语言：txt
复制
  // 创建 xhr 对象
代码语言：txt
复制
  const xhr = new XMLHttpRequest()
代码语言：txt
复制
  // 通过 onreadystatechange 事件捕获请求状态的变化
代码语言：txt
复制
  xhr.onreadystatechange = () => {
代码语言：txt
复制
    console.log(xhr.status)
代码语言：txt
复制
    console.log(xhr.readyState)
代码语言：txt
复制
    if (xhr.status === 200 && xhr.readyState === 4) {
代码语言：txt
复制
      console.log(xhr.getResponseHeader('Date'))
代码语言：txt
复制
      console.log(xhr.getResponseHeader('Access-Control-Allow-Origin'))
代码语言：txt
复制
    }
代码语言：txt
复制
  }
代码语言：txt
复制
  // 捕获错误
代码语言：txt
复制
  xhr.onerror = err => {
代码语言：txt
复制
    console.log('error:', err)
代码语言：txt
复制
  }
代码语言：txt
复制
  // 初始化请求
代码语言：txt
复制
  xhr.open('PUT', 'http://192.168.1.105:7701/config', true)
代码语言：txt
复制
    // 设置自定义头部（必须在 open 之后）
代码语言：txt
复制
    xhr.setRequestHeader('X-Custom-Header', 'foo')
代码语言：txt
复制
  // 发送请求
代码语言：txt
复制
  xhr.send(null)
代码语言：txt
复制
}
代码语言：txt
复制
xhrRequest()
代码语言：txt
复制
// Server 服务端
代码语言：txt
复制
const http = require('http')
代码语言：txt
复制
const port = 7701
代码语言：txt
复制
const allowedOrigin = 'http://192.168.1.105:8080' // 这个是我本地客户端的 Origin（源）
代码语言：txt
复制
const server = http.createServer((request, response) => {
代码语言：txt
复制
  if (request.headers.origin === allowedOrigin) {
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Origin', allowedOrigin)
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Credentials', true)
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Methods', 'PUT')
代码语言：txt
复制
  response.setHeader('Access-Control-Allow-Headers', 'X-Custom-Header')
代码语言：txt
复制
  response.setHeader('Access-Control-Expose-Headers', 'Date,Access-Control-Allow-Origin')
代码语言：txt
复制
  }
代码语言：txt
复制
  if (request.url === '/config') {
代码语言：txt
复制
    response.end(JSON.stringify({ name: 'Frankie', age: 20 }))
代码语言：txt
复制
  }
代码语言：txt
复制
})
代码语言：txt
复制
server.listen(port)
1. 预检请求

非简单请求时那种对服务器有特殊要求的请求，比如请求方法是 PUT 或 DELETE，或者 Content-Type 字段的类型是

application/json。

非简单请求的 CORS 请求，会在正式通信之前，增加一次 HTTP 查询请求，称为 预检请求 （preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些 HTTP 动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的

XMLHttpRequest 请求，否则就报错。

上面代码中，HTTP 请求的方法是 PUT，并且发送一个自定义头信息 X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个“预检请求”，要求服务器确认可以这样请求。下面是这个“预检请求”的 HTTP 头信息。

代码语言：txt
复制
OPTIONS /config HTTP/1.1
代码语言：txt
复制
Host: 192.168.1.105:7701
代码语言：txt
复制
Connection: keep-alive
代码语言：txt
复制
Accept: */*
代码语言：txt
复制
Access-Control-Request-Method: PUT
代码语言：txt
复制
Access-Control-Request-Headers: x-custom-header
代码语言：txt
复制
Origin: http://192.168.1.105:8080
代码语言：txt
复制
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
代码语言：txt
复制
Sec-Fetch-Mode: cors
代码语言：txt
复制
Referer: http://192.168.1.105:8080/
代码语言：txt
复制
Accept-Encoding: gzip, deflate
代码语言：txt
复制
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7

“预检请求”用的请求方法是 OPTIONS，表示这个请求是用来询问的。头信息里面，关键字是 Origin，表示请求来自哪个源。

除了 Origin 字段，“预检请求”的头信息包括两个特殊字段。

  • Access-Control-Request-Methodundefined这个字段是必须的，用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法，上面示例是 PUT。
  • Access-Control-Request-Headersundefined这个字段是一个逗号 , 分隔的字符串，指定浏览器 CORS 请求会额外发送的头信息字段，上面示例是 X-Custom-Header。

Tips：预检请求可以在调试器 Network 选项卡中查看，如下图：

2. 预检请求的回应

服务器收到“预检请求”以后，检查了 Origin、Access-Control-Request-Method 和 Access-Control-

Request-Headers 字段以后，确认允许跨域请求，就可以做出回应。

代码语言：txt
复制
HTTP/1.1 200 OK
代码语言：txt
复制
Access-Control-Allow-Origin: http://192.168.1.105:8080
代码语言：txt
复制
Access-Control-Allow-Credentials: true
代码语言：txt
复制
Access-Control-Allow-Methods: PUT
代码语言：txt
复制
Access-Control-Allow-Headers: X-Custom-Header
代码语言：txt
复制
Access-Control-Expose-Headers: Date,Access-Control-Allow-Origin
代码语言：txt
复制
Date: Sun, 06 Jun 2021 15:27:27 GMT
代码语言：txt
复制
Connection: keep-alive
代码语言：txt
复制
Keep-Alive: timeout=5
代码语言：txt
复制
Content-Length: 27

上面的 HTTP 回应中，关键的是 Access-Control-Allow-Origin 字段，表示

http://192.168.1.105:8080 可以请求数据。该字段也可以设为 *，表示同意任意的跨源请求。（本示例携带了 Cookie

信息，不可设为 *）

代码语言：txt
复制
Access-Control-Allow-Origin: *

如果服务器否定了“预检请求”，会返回一个正常的 HTTP 回应，但是没有任何的 CORS

相关的头信息字段。这是，浏览器就认定，服务器不同意预检请求，因此触发一个错误，被 XMLHttpRequest 对象的 onerror

回调函数捕获。

如果将服务端的 Access-Control-Allow-Headers 注释掉：

代码语言：txt
复制
// response.setHeader('Access-Control-Allow-Headers', 'X-Custom-Header')

控制台会打印出如下的报错信息：

服务器回应的其他 CORS 相关字段如下：

代码语言：txt
复制
Access-Control-Allow-Methods: PUT
代码语言：txt
复制
Access-Control-Allow-Headers: X-Custom-Header
代码语言：txt
复制
Access-Control-Allow-Credentials: true
代码语言：txt
复制
Access-Control-Max-Age: 1728000
  • Access-Control-Allow-Methodsundefined这个字段是必须的，它的值是逗号 , 分隔的一个字符串，表明服务器支持的所有跨域请求。注意，返回的是 所有 支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次“预检请求”。(本示例仅设置了一个 PUT 方法。)
  • Access-Control-Allow-Headersundefined如果浏览器请求包括 Access-Control-Request-Headers 字段，则 Access-Control-Allow-Headers 字段是必须的，它也是一个逗号 , 分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在“预检请求”的字段。
  • Access-Control-Allow-Credentialsundefined这个字段与简单请求时的含义相同。
  • Access-Control-Max-Ageundefined这个字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是 20 天（1728000 秒），即允许缓存该条回应 1728000 秒（即 20 天），在此期间，不用发出另一条预检请求。
3. 浏览器的正常请求和回应

一旦服务器通过了“预检请求”，以后每次浏览器正常的 CORS 请求，就都跟简单请求一样，会有一个 Origin 头信息字段。服务器的回应，也都会有一个

Access-Control-Allow-Origin 头信息字段。

下面是“预检请求”之后，浏览器的正常 CORS 请求的请求报文。

代码语言：txt
复制
PUT /config HTTP/1.1
代码语言：txt
复制
Host: 192.168.1.105:7701
代码语言：txt
复制
Connection: keep-alive
代码语言：txt
复制
Content-Length: 0
代码语言：txt
复制
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
代码语言：txt
复制
X-Custom-Header: foo
代码语言：txt
复制
Accept: */*
代码语言：txt
复制
Origin: http://192.168.1.105:8080
代码语言：txt
复制
Referer: http://192.168.1.105:8080/
代码语言：txt
复制
Accept-Encoding: gzip, deflate
代码语言：txt
复制
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
代码语言：txt
复制
Cookie: username=Frankie

上面的头信息的 Origin 字段是浏览器自动添加的。

下面是服务器正常的响应报文。

代码语言：txt
复制
HTTP/1.1 200 OK
代码语言：txt
复制
Access-Control-Allow-Origin: http://192.168.1.105:8080
代码语言：txt
复制
Access-Control-Allow-Credentials: true
代码语言：txt
复制
Access-Control-Allow-Methods: PUT
代码语言：txt
复制
Access-Control-Allow-Headers: X-Custom-Header
代码语言：txt
复制
Access-Control-Expose-Headers: Date,Access-Control-Allow-Origin
代码语言：txt
复制
Date: Sun, 06 Jun 2021 15:40:11 GMT
代码语言：txt
复制
Connection: keep-alive
代码语言：txt
复制
Keep-Alive: timeout=5
代码语言：txt
复制
Content-Length: 27

上面的头信息中，Access-Control-Allow-Origin 字段是每次回应都必定包含的。

五、与 JSONP 的比较

CORS 与 JSONP 的使用目的相同，但是比 JSONP 更强大。

JSONP 只支持 GET 请求，CORS 支持所有类型的 HTTP 请求。JSONP 的优势在于支持老式浏览器，以及可以向不支持 CORS

的网站请求数据。

六、其他

以下内容可能与 CORS 无关，不想看可跳过。

1. HTTP headers 之 Referer

Referer 请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。服务端一般使用 Referer

请求头识别访问来源，可能会以此进行统计分析、日志记录以及缓存优化等。

注意，如果直接在地址栏输入 URL 访问某网页，这时 Referer 为空。

例如，上面示例中请求 /config 接口的网页地址是 http://192.168.1.105:8080/#/about，从请求报文可以大致看到

Origin 与 Referer 的区别。

代码语言：txt
复制
Origin: http://192.168.1.105:8080
代码语言：txt
复制
Referer: http://192.168.1.105:8080/
  • OriginundefinedOrigin 的值可以置空或者是 <scheme>://<host> [:<port>]，即协议 + 主机 + 端口。其中主机是指域名或者 IP 地址；端口号可选，缺省时为服务的默认端口（例如 HTTP 请求默认端口是 80，HTTPS 请求默认端口是 443）
  • Refererundefined当前页面被链接而至的前一页面的绝对路径或者相对路径。不包含 URL fragments (例如 "#section") 和 userinfo (例如 "https://username:password@example.com/foo/bar/" 中的 "username:password" )。

上面的解释比较官方，换句话说就是从哪个页面链接过来的。例如，我从 GitHub 仓库点击跳转至简书文章，可以从 HTML 的请求报文看到：

代码语言：txt
复制
Host: www.jianshu.com
代码语言：txt
复制
Referer: https://github.com/toFrankie/csscomb-mini

假设有一个需求是统计从 GitHub 访问简书的访问量，那么就可以通过 Referer 来实现。也常用于防盗链等。

需要注意的是，Referer 的正确英语拼法是 referrer 。由于早期 HTTP 规范的拼写错误，为保持向下兼容就将错就错了。例如 DOM Level 2、Referrer Policy 等其他网络技术的规范曾试图修正此问题，使用正确拼法，导致目前拼法并不统一。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

access
http
https
网络安全

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

access
http
https
网络安全
评论
作者已关闭评论
0 条评论
热度
最新
作者已关闭评论
推荐阅读
LV.
文章
0
获赞
0
目录
  • 一、简介
  • 二、同源安全策略
  • 三、两种请求
  • 三、简单请求
    • 1. 基本流程
      • 2. withCredentials 属性
      • 四、非简单请求
        • 1. 预检请求
          • 2. 预检请求的回应
            • 3. 浏览器的正常请求和回应
            • 五、与 JSONP 的比较
            • 六、其他
              • 1. HTTP headers 之 Referer
              相关产品与服务
              云服务器
              云服务器（Cloud Virtual Machine，CVM）提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源，适应变化的业务需求，并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本，简化 IT 运维工作。
              产品介绍产品文档
              2核2G服务器新用户限时秒杀28元/年
              领券

              腾讯云开发者

              扫码关注腾讯云开发者

              扫码关注腾讯云开发者

              领取腾讯云代金券

              热门产品

              热门推荐

              更多推荐

              Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 

              深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

              腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287

              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档

              Copyright © 2013 - 2024 Tencent Cloud.

              All Rights Reserved. 腾讯云 版权所有

              作者已关闭评论