使用 boto 的 django-storages - 无法上传 mp3，但可以上传图像。另外，还承受着 HTTP 307 的痛苦
我使用 django-storages (1.1.4) 的 boto (2.2.1) 后端将文件上传到 S3 存储桶。它适用于图像，但当我尝试上传电影文件（小 mov、小 avi）或 mp3 时，我收到“管道损坏”错误。
这很奇怪。
深入研究 Django 回溯，我看到以下异常：
boto.https_connection.InvalidCertificateException
哪种适合我使用 Cyberduck 直接检查存储桶的体验：有时它抱怨我的 * 证书之间不匹配.s3.amazonaws.com 和域 *.s3-external-3.amazonaws.com
事实上，存储桶日志记录显示我正在接受 HTTP 307 临时重定向。 AWS 是否可能以一种方式发送某些内容类型，而以另一种方式发送其他内容类型，但 boto/something 无法完全跟上？电影的上传似乎确实击中了 S3 两次，而图像则击中了一次，因此 boto 很可能正在应对 307 罚款（boto 中 307 支持的封闭票据已经有几年了），因此它可以好吧，还有别的事情发生。
但什么？我从愉快而富有成效的一天变成了低谷，这非常令人沮丧。
对于可能发生的情况和/或尝试解决此问题有什么建议吗？
（请注意，这对于 boto S3 后端或简单的 S3 后端会失败 - 只是 boto 给了我看起来更具体的错误）
Am using the boto (2.2.1) backend for django-storages (1.1.4) to upload files to an S3 bucket. It works fine for images, but when I try to upload movie files (small mov, small avi) or an mp3, i get a Broken pipe error.
This is Weird.
Digging into the Django traceback, I get see the following exception:
boto.https_connection.InvalidCertificateException
Which kind of fits the experience I've been having using Cyberduck to inspect the bucket directly: sometimes it complains that I'm getting a mismatch between the cert for *.s3.amazonaws.com and the domain *.s3-external-3.amazonaws.com
Indeed, the bucket logging shows that I'm being served a HTTP 307 temporary redirect. Is it perhaps AWS sending some content types one way and others another, but boto/something can't quite keep up with that? Uploads of movies do seem to hit S3 twice, whereas images hit it once, so it may well be that boto is coping with the 307 fine (and the closed tickets for 307 support in boto are a couple of years old), so it could well be ok and something else is up.
But what? I've gone from a pleasantly productive day to a head end, and it's extremely frustrating.
Any suggestions for what may be up and/or what to try to work around this?
(Note that this fails with the boto S3 backend or the simple S3 backend - it's just that the boto one gives me what looks like a more specific error)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我写这个作为答案，因为它太长，无法容纳评论。它并不能真正回答您的问题，但也许可以帮助您找到答案。
您收到的 307 重定向正在发生，因为存储桶位于 eu-west-1 中，但您正在访问标准 s3.amazonaws.com 端点。 S3 使用一些 DNS 魔法和 HTTP 重定向将流量从通用 S3 端点路由到正确的区域端点。
为了实现这一点，大多数 S3 客户端使用“子域”引用方案，将存储桶名称添加到请求中的主机名前面。因此，如果您尝试访问您的存储桶，则请求中的 Host 标头在 boto 中默认为 foofoofoo-bar.s3.amazonaws.com，然后使用 DNS 魔法和 HTTP 重定向，S3 最终会获取您的存储桶。请求到正确的地方。这一切都应该在博托自动发生。
如果您的存储桶名称包含“.”，此方法可能会导致问题。因为主机标头可能是 foofoofoo.bar.s3.amazonaws.com，并且由于 S3 端点上的通配符 SSL 证书仅适用于一级子域，因此存储桶名称中的句点会导致 SSL 证书验证失败。
这就是为什么我问“。”在你的存储桶名称中，但显然这不是问题。您是否可以从日志中提供更多上下文？我想看看证书验证错误之前发生了什么。
I'm writing this as an answer because it is too long to fit in a comment. It doesn't really answer your question but perhaps it will help you get to an answer.
The 307 redirect you are getting is happening because the bucket is in eu-west-1 but you are hitting the standard s3.amazonaws.com endpoint. S3 uses some DNS magic and HTTP redirects to route traffic from the generic S3 endpoint to the correct regional endpoint.
To accomplish this, most S3 clients use a "subdomain" referencing scheme that prepends the bucket name to the hostname in the request. So, if you are trying to access your bucket the Host header in the request would, by default in boto, be foofoofoo-bar.s3.amazonaws.com and then, using the DNS magic and HTTP redirects, S3 would end up getting your request to the right place. That should all happen automatically in boto.
This approach can cause a problem if your bucket name includes a "." because then the Host header might be foofoofoo.bar.s3.amazonaws.com and, since the wildcard SSL cert on the S3 endpoint is only good for one level of subdomain, the period in the bucket name then causes the SSL cert verification to fail.
That's why I asked about "." in your bucket name but apparently that is not the problem. Is there anyway you could provide more context from the logs? I would like to see what's happening prior to the cert validation error.