三天后 Cloud Storage 下载 URL 失败，可能是由于 Content-Type？

Question

三天后，我的 Cloud Storage 签名下载 URL 失败。我想我已经解决了这个问题，所以这个问题可能是其他人的解决方案。三天后问我这个解决方案是否有效！

这是完整的错误信息：

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.
</Message>
<StringToSign>
GET 1742169600 /languagetwo-cd94d.appspot.com/Audio%2FSpanish%2FLatin_America-Sofia-Female-IBM%2Fagua.mp3
</StringToSign>
</Error>

我用谷歌搜索了错误消息，并看到一些讨论表明问题出在Content-Type。将文件上传到存储时，我没有在代码中指定 Content-Type。当我在代码中设置 contentType 时，上传下载 URL 时立即失败，并显示相同的错误消息。这表明我走在正确的轨道上。

file.getSignedUrl({
  action: 'read',
  expires: '03-17-2025', 
  contentType: 'audio/mp3'
})

下载 URL 中的到期日期是 2025 年 3 月 17 日，所以这不是问题。

Google 关于Signed URLs 的文档说语法是Content_Type。 content-type 上的 IETF 文档说语法是 Content-Type。我试过了

file.getSignedUrl({
    action: 'read',
    expires: '03-17-2025',
    content_type: 'audio/mp3'
})

和我的文件下载和播放。我不想等待三天才能看到他们是否继续工作，所以请告诉我是否还有其他需要解决的问题！

只是为了我尝试过的笑容

file.getSignedUrl({
    action: 'read',
    expires: '03-17-2025',
    content-type: 'audio/mp3'
})

而firebase deploy 不会接受该代码。键中不允许使用连字符。

Google 关于签名 URL 的文档说

As needed. If you provide a content-type, the client (browser) must provide this HTTP header set to the same value.

As needed 与 Optional 不同。

我的 .mp3 文件和我的 .webm 下载 URL 都失败了，因此文件的内容是什么并不重要。

Answer 1

三天后，我的下载 URL 仍然有效。好像

file.getSignedUrl({
    action: 'read',
    expires: '03-17-2025',
    content_type: 'audio/mp3'
})

就是答案。