所以我有一个 python 网络应用程序，它获取用户上传的图像并将它们推入 S3 以使用 boto3 进行存储，如下所示：
s3.Object(BUCKET_NAME, filename).put(Body=file_obj.read(), ContentType="image/*")
我的印象是您需要在上传时指定正确的内容类型（即图像/jpeg、图像/bmp 等），否则 S3 将无法正确处理文件，但这似乎不是案例。
我使用“图像/*”的内容类型对它进行了测试，根本没有内容类型，一切似乎都工作正常 - 图像上传和存储都很好，重新下载时它们没有损坏或任何东西。
到目前为止，我看到的唯一区别是，如果没有内容类型，您的 Web 浏览器将下载文件，而不是在新选项卡中显示图像（使用 S3 管理控制台时）
这个结论正确吗？内容类型仅决定浏览器如何处理相关文件，还是 S3 将其用于其他用途？
【问题讨论】：
你是对的。
S3 不使用 Content-Type 做任何事情。
用户代理（浏览器）——正如您所注意到的——信息需要可用（并且正确）。
还有几个类似的，例如Content-Encoding、Cache-Control、Expires 和Content-Disposition——S3 只是在获取对象时将这些与响应一起返回，以使浏览器受益。这些不会改变 S3 的行为。
还有一个使用预签名 URL 的 interesting capability for GET requests，您可以在其中要求 S3 覆盖存储的值并在响应中返回不同的内容。在查询字符串中带有response-content-type=application/octet-stream 的签名 URL 将触发S3 为该单个响应返回Content-Type: application/octet-stream，无论您在S3 中存储了什么。
只有 x-amz-* 标头，排除那些匹配 x-amz-meta-* 的标头实际上会导致 S3 的行为变化，例如 x-amz-acl 和 x-amz-storage-class。
还有几个其他标头打破了这种一般模式，也许值得单独提及：
X-Robots-Tag 似乎完全没有记录，但在上传时也被接受并与每个GET 返回浏览器，所以这里的行为很像Content-Type 和上面提到的朋友。 S3 不会基于它采取任何行动。此标头用于向行为良好的爬虫发出信号，类似于/robots.txt。一个常见的值是X-Robots-Tag: noindex, nofollow（不要索引这个页面，不要点击这个页面上的链接）。每次下载都会返回此标头，但只能通过 API 设置。它在控制台中可见，但不能通过控制台设置或编辑。这是一个隐秘的功能，据我所知完全没有记录。
Content-MD5 是随上传发送的可选（但强烈推荐）请求标头。它包含请求正文的二进制 md5，以 base64 编码。此标头在您获取对象时不返回，但用于验证上传是否已损坏。如果请求正文与此哈希不匹配，则上传会被 S3 拒绝并出现错误，并且永远不会保存。
【讨论】：