上传到文件选择器时的md5校验和

Question

背景

我正致力于将现有应用与文件选择器集成。在我们现有的设置中，我们依靠md5校验和来确保数据完整性。据我所知，文件选择器在响应REST API上传（也不使用JavaScript客户端）时不提供任何md5。

S3存储，md5和数据完整性

我们正在使用S3进行存储，据我所知，您可以在storing files时为S3提供md5校验和，以便亚马逊可以验证并拒绝存储请求，如果数据似乎是错误的。

  

要确保数据没有损坏遍历网络，请使用Content-MD5标头。当您使用此标头时，Amazon S3会根据提供的MD5值检查对象，如果它们不匹配，则会返回错误。此外，您可以在将对象放入Amazon S3时计算MD5，并将返回的ETag与计算的MD5值进行比较。

我调查了亚马逊返回的etag标题，发现它并不清楚实际返回的是etag。 Java documentation州：

  

获取由Amazon S3计算的此对象内容的十六进制编码的128位MD5哈希值。

Ruby文档声明：

  

通常，ETAG是对象的MD5。如果使用分段上传来上传对象，则这是MD5所有upload-part-md5s

their documentation中的另一个地方我发现了这个：

  

实体标签是对象的哈希值。 ETag仅反映对象内容的更改，而不是元数据。在创建对象时确定ETag。对于由PUT对象操作和POST对象操作创建的对象，ETag是一个带引号的32位十六进制字符串，表示对象数据的MD5摘要。对于其他对象，ETag可能是也可能不是对象数据的MD5摘要。如果ETag不是对象数据的MD5摘要，它将包含一个或多个非十六进制字符和/或将包含少于32个或超过32个十六进制数字。

This seems描述了如何在S3上实际计算etag，而this stack overflow post似乎意味着同样的事情：Etag不可信任总是等于文件MD5。

所以 - 这是我的问题

1. 一般来说，文件选择器如何将文件存储到s3？是否使用了多部分职位申请？
2. 我看到当我针对例如https://www.filepicker.io/api/file/<file handle>执行HEAD请求时，我确实得到了一个etag标题。我回来的etag确实与我上传的文件的md5相匹配。是否直接从S3中返回了标题？或者这实际上是由filepicker计算的md5，我可以信任吗？
3. 是否可以对文件选择器API的客户端返回md5的明确声明？例如，当我们POST一个文件时，我们得到一个JSON结构，包括文件的URL和它的大小。可以将md5包含在这里吗？
4. 是否可以为文件选择器提供md5，而md5又会在将文件发布到S3时使用，以便我们可以对文件进行端到端检查？

Answer 1

1. 是的，我们使用python boto库来具体。
2. ETag从S3开始。
3. ＆安培;它已被考虑并且在我们的积压中，但尚未实施。