前端跨域请求：CORS 机制和最佳实践

前端 CORS 请求梳理

导言

随着现代 Web 应用程序的前后端分离，跨域请求已成为一个不可避免的问题。本文旨在梳理前端 CORS（跨域资源共享）请求，帮助开发人员深入了解其机制并有效解决跨域问题。

CORS 请求的本质

CORS 是一种浏览器安全机制，它规定了一个域名的资源（例如：脚本、图像、字体）是否可以被另一个域名的页面获取。当一个 Web 页面从与自身域不同的域加载资源时，就会触发 CORS 请求。

CORS 请求类型

CORS 请求分为两种类型：简单请求和非简单请求。

简单请求

• 使用 GET、HEAD、POST 方法。
• 仅发送简单头部（例如：Content-Type、Accept、Accept-Language）。
• 不包含自定义头部字段（例如：X-My-Custom-Header）。
• 不会触发 CORS 预检请求。

非简单请求

• 使用除 GET、HEAD、POST 之外的其他方法（例如：PUT、DELETE）。
• 发送非简单头部（例如：X-My-Custom-Header）。
• 会触发 CORS 预检请求（OPTIONS 请求）。

CORS 预检请求

对于非简单请求，浏览器会在实际请求之前发送一个预检请求（OPTIONS 请求）到目标服务器。预检请求的作用是查询目标服务器是否允许跨域请求。

预检请求包含以下头部：

• Origin：请求源域名。
• Access-Control-Request-Method：实际请求的方法。
• Access-Control-Request-Headers：实际请求的头部。

服务器根据预检请求信息，返回以下响应头部：

• Access-Control-Allow-Origin：允许跨域请求的域名。
• Access-Control-Allow-Methods：允许跨域请求的方法。
• Access-Control-Allow-Headers：允许跨域请求的头部。
• Access-Control-Max-Age：预检请求结果的缓存时间（以秒为单位）。

解决跨域请求的最佳实践

服务端配置 CORS

• 在服务器端配置 CORS 响应头部，允许跨域请求。
• 具体配置方式因服务器环境而异。

前端使用 fetch API

• 使用 fetch API 发起 CORS 请求。
• fetch API 会自动处理 CORS 预检请求。

使用 CORS 代理

• 如果服务端无法配置 CORS，可以使用 CORS 代理，如：CORS Anywhere。
• CORS 代理会转发跨域请求，并在其上添加适当的 CORS 响应头部。

常见问题与解答

为什么某些请求不会触发 CORS 预检请求？

• 简单请求不会触发 CORS 预检请求。
• 某些浏览器对预检请求的频率有限制，以避免性能问题。

为什么 OPTIONS 请求没有返回 CORS 响应头部？

• OPTIONS 请求本身并不是一个 CORS 请求，因此不会返回 CORS 响应头部。
• CORS 响应头部仅在实际请求中返回。

使用 CORS 代理的缺点是什么？

• CORS 代理可能会影响性能，因为它们需要对请求进行转发。
• CORS 代理可能会引入安全隐患，因为它们充当了跨域请求的中间人。

结语

掌握 CORS 请求的机制和最佳实践对于解决前端跨域问题至关重要。通过仔细考虑请求类型、预检请求以及服务端和前端的配置，开发者可以确保跨域请求的顺利进行，为用户提供无缝的 Web 体验。