为什么 AWS JS SDK S3::Bucket#upload 使用意外 Access-Control-Request-Method

Why does AWS JS SDK S3::Bucket#upload use unexpected Access-Control-Request-Method

我看到一个奇怪的问题,即对 AWS S3 的 CORS 请求(特别是 OPTIONS)间歇性失败(~1/3 次尝试)并出现 403 响应代码和以下错误消息:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://s3.amazonaws.com/some-bucket/some-video.mp4?uploads. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

S3 CORS 配置 应该 足够宽容以允许我之后的用例(上传 mp4)和其他资产上传(图像,CSS , JS, 等)到同一个桶,使用相同的函数(包装 AWS-SDK 的 Bucket#upload)工作没有失败。

有谁知道为什么会这样?我可以防止SDK使用意外的Access-Control-Request-Method header吗?

更新:经过更多的挖掘,我得出的结论是,这是因为 OPTIONS 请求 有时 Access-Control-Request-Method: POST header 而不是默认的 Access-Control-Request-Method: PUT。我的 CORS 配置中没有 POST 白名单,这似乎就是这些请求失败的原因。

有谁知道为什么会这样?这是SDK中的错误吗?文档中的疏忽?文档*暗示将发布 PUT,因此我认为两者存在冲突。

*此方法来自 the documentation

Bucket — (String) Name of the bucket to which the PUT operation was initiated.

Key — (String) Object key for which the PUT operation was initiated.

这是文档中的一个错误。 upload()的描述暗示与此矛盾。

upload(params = {}, [options], [callback]) ⇒ AWS.S3.ManagedUpload

Uploads an arbitrarily sized buffer, blob, or stream, using intelligent concurrent handling of parts if the payload is large enough.

S3 处理文件上传“部分”的唯一方法是通过分段 API,POST /...?uploads 是启动分段上传的 S3 REST API 中的子资源请求,这对大于 5 GB 的对象是强制性的,并且在文件大小超过一定数量的 MB 时推荐使用。 Multipart 也是唯一可以重试部分失败的上传而无需重新发送整个文件的机制。

您的 CORS 策略应该允许 POST