Google Cloud Storage OPTIONS请求缺失CORS响应头问题

我之前也碰到过几乎一模一样的问题，当时折腾了好一阵子才搞明白GCS处理预飞行OPTIONS请求的特殊逻辑，给你几个关键的修复点：

1. 补充CORS配置中的核心响应头 #

你的现有CORS规则里的responseHeader缺少了两个预飞行请求必须的关键项：Access-Control-Allow-Headers和Access-Control-Allow-Methods。浏览器需要这两个响应头来确认后续的PUT请求是否符合跨域要求。

修改后的完整CORS配置如下：

[
  {
    "origin": ["http://localhost:8080"],
    "responseHeader": [
      "Content-Type",
      "Access-Control-Allow-Origin",
      "Access-Control-Allow-Headers",
      "Access-Control-Allow-Methods",
      "Origin"
    ],
    "method": ["GET", "HEAD", "DELETE", "POST", "PUT", "OPTIONS"],
    "maxAgeSeconds": 3600
  }
]

其中Access-Control-Allow-Headers会告诉浏览器哪些请求头是被允许的，Access-Control-Allow-Methods则明确列出允许的HTTP方法，这两个是预飞行请求通过的核心前提。

2. 确保配置正确生效 #

修改完配置后，一定要用gsutil命令重新应用配置，并且等待1-2分钟让GCS同步生效（偶尔会有延迟）：

gsutil cors set your-cors-config.json gs://your-bucket-name

可以用以下命令验证配置是否正确上传：

gsutil cors get gs://your-bucket-name

为什么之前的修改无效？ #

你提到改成origin: *也没用，其实问题根源不在origin，而是预飞行请求需要的响应头没有被配置。GCS对预飞行OPTIONS请求的响应规则比实际业务请求更严格，必须明确返回Access-Control-Allow-Headers和Access-Control-Allow-Methods，否则浏览器会直接判定跨域不通过，不会发送后续的PUT请求。

另外需要注意：签名URL的OPTIONS请求是匿名的（不会携带签名参数），但只要你的CORS规则允许对应的origin和方法，就会正确返回CORS响应头，这点不需要额外处理签名逻辑。

内容的提问来源于stack exchange，提问作者Milan