我们在S3模式下使用Fine Uploader来对抗非传统的，虽然符合S3标准的服务。它使用一个不寻常的主机名和端口。使用如下有效负载调用/ signature / endpoint：
{“headers”：“POST \ n \ nimage / jpeg \ n \ nx-amz-acl：private \ nx-amz-date：Tue，05 Aug 2014 20:28:11 GMT \ nx-amz-meta -qqfilename：Pomegranate.jpg \ N / service-fqdn.com / 37b5165cf4fd.jpg上传“}
换句话说，Fine（非常合理地）将其视为CNAME样式的虚拟托管存储桶并相应地生成StringToSign。实际上，service-fqdn.com是自身的服务端点，StringToSign中指定的规范资源应该只是：
/bucketname/37b5165cf4fd.jpg?uploads
在此配置中，路径上提供了bucketname，而不是域名的一部分。
手动修补/ signature / endpoint中的传入StringToSign会导致上传成功。
那么配置Fine Uploader以了解service-fqdn.com是服务端点的正确方法是什么？ [为了比较，在常见的s3curl.pl实用程序中，需要使用已知端点列表修改源代码。]
谢谢，
答案 0 :(得分：0)
Fine Uploader S3目前期望所有端点都是实际的S3存储桶。有计划更新S3代码，以允许上传与任何＆＃34;行为类似的服务无缝地工作。一个S3端点。部分工作涉及allowing uploads to a CloudFront distribution。一些内部讨论表明，我们将以这样的方式解决CF发行版功能，即上传到任何类似S3的端点将作为结果。
在此之前，正如您所说，用于确定存储桶名称的逻辑需要进行调整。
作为旁注，除非我记错了，否则我相信我们已通过电子邮件说明了您的具体用例。如果我是对的，我会鼓励你在七月份开始的电子邮件主题中提出这个问题。