使用boto（2.2.1）后端进行django-storages（1.1.4）将文件上传到S3存储桶。它适用于图像，但是当我尝试上传电影文件（小型电影，小型AVI）或mp3时，我收到了一个破损的管道错误。
这很奇怪。
深入研究Django追踪，我看到以下异常：
boto.https_connection.InvalidCertificateException
我使用Cyberduck直接检查存储桶时遇到的体验是什么样的：有时它会抱怨我*.s3.amazonaws.com的证书与域*.s3-external-3.amazonaws.com <之间存在不匹配/ p>
实际上，存储桶日志记录显示我正在为HTTP 307临时重定向服务。也许是AWS以一种方式发送一些内容类型而另一种方式发送内容类型，但boto / something无法完全跟上它？电影的上传似乎确实击中了S3两次，而图像击中它一次，所以很可能是boto正在处理307罚款（并且boto的307支持的已关闭门票是几年），所以它可以好吧，还有其他事情发生了。
但是什么？我已经从一个愉快的一天变成了一个头脑，而且非常令人沮丧。对可能出现的问题和/或尝试解决此问题的任何建议？
（请注意，这与boto S3后端或简单的S3后端失败 - 只是boto让我看起来更具体的错误）
答案 0 :(得分：3)
我正在写这个作为答案，因为它太长而不适合评论。它并没有真正回答你的问题，但也许它会帮助你得到答案。
您正在获得的307重定向正在发生，因为存储桶位于eu-west-1但您正在使用标准的s3.amazonaws.com端点。 S3使用一些DNS魔术和HTTP重定向将流量从通用S3端点路由到正确的区域端点。
为实现此目的，大多数S3客户端使用“子域”引用方案，该方案将存储桶名称添加到请求中的主机名。因此，如果您尝试访问您的存储桶，请求中的主机标头（默认情况下为boto）将为foofoofoo-bar.s3.amazonaws.com，然后使用DNS魔术和HTTP重定向，S3将最终获得您的请求到正确的地方。这应该全部自动发生在boto。
如果您的存储桶名称包含“。”，则此方法可能会导致问题。因为然后Host标头可能是foofoofoo.bar.s3.amazonaws.com，并且由于S3端点上的通配符SSL证书仅适用于一个级别的子域，因此存储桶名称中的句点会导致SSL证书验证失败
这就是我询问“。”的原因。在你的桶名称，但显然这不是问题。无论如何，您可以从日志中提供更多上下文吗？我想看看在验证错误之前发生了什么。