为什么签名 URL 的 Cache-Control 会失败？答案

【问题标题】：Why does Cache-Control fail for signed URLs?为什么签名 URL 的 Cache-Control 会失败？
【发布时间】：2019-06-06 17:53:12
【问题描述】：

我正在尝试使用签名 URL V2 创建一个包含 cache-control 标头的签名 URL。

当我创建这样的 URL 时，该 URL 有效且有效。

        String signature = "PUT" + "\n" +
                "\n" +
                contentType + "\n" +
                expiresWhen + "\n" +
                "x-goog-acl:public-read" + "\n" +
                path;

但是当我添加 cache-control 标头时，我在尝试上传时得到 403：

        String signature = "PUT" + "\n" +
                "\n" +
                contentType + "\n" +
                expiresWhen + "\n" +
                "cache-control:public,max-age=600" + "\n" +
                "x-goog-acl:public-read" + "\n" +
                path;

我唯一改变的是标题。标头按字母排序，不包含空格，并用“\n”分隔，因此应满足所有要求。还是我在这里犯了错误？我假设public,max-age 必须保持这个顺序而不是排序。如果上传时指定相同，可能没问题。

然后我发现了这个问题Google Cloud Storage set cache-control with signed urls upload，但我认为它不适用，因为我们是从服务器上传的，而不是从浏览器上传的。我的假设正确吗？

【问题讨论】：

将cache-control 设置为 600 仅在我将其添加到请求时对我有效，但显然它不能成为签名的一部分。这是正确的吗？
签名 URL 不关心您是在浏览器中运行还是通过 curl 命令运行，前提是不存在 CORS 问题。如果您使用的是 CDN，则会忽略签名 URL 的 Cache-Control。使用签名 URL 时，您是调用者（客户端），而不是服务器。 Cache-Control 不是客户端管理的东西。因此，不要尝试设置它，因为没有意义。您可以在 Cloud Storage 中为对象设置 Cache-Control 标头，但我尚未使用签名 URL 验证结果。
我不能在签名的 URL 中包含 cache-control，但如果客户端将其发送到 GCS 进行上传并将 cache-control 添加到调用中，它就会成为上传对象的一部分。 IMO 这没有意义，因为上传者可以在我的商店中指定一个我无法控制的属性。这不是控制签名 URL 的用途吗？
不，缓存控制是发送给客户端的服务器端属性，而不是相反。对 Cloud Storage 中的对象设置缓存控制，而不是在对 Cloud Storage 的请求中。

标签： google-cloud-platform google-cloud-storage

【解决方案1】：

在后端启用签名 URL 处理时，Cloud CDN 会对带有签名 URL 的请求进行特殊处理。具体来说，带有 Signature 查询参数的请求被视为已签名。收到此类请求后，Cloud CDN 会验证以下内容：

HTTP 方法是 GET 或 HEAD。 Expires 参数设置为未来时间。请求的签名与使用命名密钥计算的签名匹配。

如果这些检查中的任何一个失败，则会提供 403 Forbidden 响应。

正如我们从 John Hanley 的评论中读到的，如果您使用的是 CDN，则签名 URL 的缓存控制将被忽略。我附上下一个链接：

https://cloud.google.com/cdn/docs/using-cdn

【讨论】：