背景
我正在努力将现有的应用程序与File Picker集成 . 在我们现有的设置中，我们依靠md5校验和来确保数据完整性 . 据我所知，文件选择器在响应REST API上传（也不使用JavaScript客户端）时不提供任何md5 .
S3存储，md5和数据完整性
我们使用S3进行存储，据我所知，当storing files时，您可以为S3提供md5校验和，以便亚马逊可以验证并拒绝存储请求，如果数据似乎是错误的 .
要确保数据没有损坏遍历网络，请使用Content-MD5标头 . 当您使用此标头时，Amazon S3会根据提供的MD5值检查对象，如果它们不匹配，则会返回错误 . 此外，您可以在将对象放入Amazon S3时计算MD5，并将返回的ETag与计算的MD5值进行比较 .
我已经调查了亚马逊返回的etag Headers ，并发现目前还不清楚实际返回的是etag . Java documentation表示：
获取由Amazon S3计算的此对象内容的十六进制编码的128位MD5哈希 .
Ruby文档说明：
通常，ETAG是对象的MD5 . 如果使用分段上传来上传对象，则这是MD5所有upload-part-md5s
their documentation中的另一个地方我发现了这个：
entity标签是对象的哈希值 . ETag仅反映对象内容的更改，而不是元数据 . 在创建对象时确定ETag . 对于由PUT对象操作和POST对象操作创建的对象，ETag是一个带引号的32位十六进制字符串，表示对象数据的MD5摘要 . 对于其他对象，ETag可能是也可能不是对象数据的MD5摘要 . 如果ETag不是对象数据的MD5摘要，则它将包含一个或多个非十六进制字符和/或将包含少于32个或多于32个十六进制数字 .
This seems描述了如何在S3上实际计算etag，并且this stack overflow post似乎意味着同样的事情：Etag不可信任总是等于文件MD5 .
所以 - 这是我的问题
-
一般来说，文件选择器如何将文件存储到s3？是否使用了多部分帖子请求？
-
我看到当我针对例如
https://www.filepicker.io/api/file/<file handle>执行HEAD请求时，我确实得到了一个etag Headers . 我回来的etag确实与我上传的文件的md5相匹配 . 是否直接从S3中返回了 Headers ？或者这实际上是由filepicker计算的md5，我可以信任吗？ -
是否可以将md5的明确声明返回给File Picker 's API? For instance when we POST a file we get a JSON structure back including the URL to the file and it' s大小的客户端 . md5可以包含在这里吗？
-
是否可以为文件选择器提供md5，而md5又会在将文件发布到S3时使用，以便我们可以对文件进行端到端的检查？
1 回答
是的，我们使用python boto库来具体 .
ETag从S3撤出 .
＆4 . 它已经实施了's been considered and is in our backlog, but hasn' .