Фон
Я работаю над интеграцией существующего приложения с File Picker. В нашей существующей настройке мы полагаемся на контрольные суммы md5 для обеспечения целостности данных. Насколько я понимаю, File Picker не предоставляет никаких md5, когда они отвечают на загрузку через REST API (и не используют клиент JavaScript).
Хранение S3, MD5 и целостность данных
Мы используем S3 для хранения, и, насколько мне известно, вы можете предоставить S3 контрольную сумму md5, когда хранение файлов, чтобы Amazon мог проверить и отклонить запрос на сохранение, если данные кажутся неверными.
Чтобы гарантировать, что данные не будут повреждены при передаче по сети, используйте заголовок Content-MD5. Когда вы используете этот заголовок, Amazon S3 проверяет объект на соответствие предоставленному значению MD5 и, если они не совпадают, возвращает ошибку. Кроме того, вы можете рассчитать MD5 при помещении объекта в Amazon S3 и сравнить возвращенный ETag с рассчитанным значением MD5.
Я немного исследовал заголовок etag, который Amazon возвращает, и обнаружил, что неясно, что на самом деле возвращается как etag. Документация Java гласит:
Получает 128-битный MD5-хэш содержимого этого объекта в шестнадцатеричном коде, вычисленный Amazon S3.
Документация Ruby гласит:
Обычно ETAG - это MD5 объекта. Если объект был загружен с использованием многостраничной загрузки, то это MD5, все файлы upload-part-md5s
В другом месте их документации я нашел это:
Тег объекта - это хэш объекта. ETag отражает только изменения содержимого объекта, но не его метаданных. ETag определяется при создании объекта. Для объектов, созданных операциями PUT Object и POST Object, ETag представляет собой 32-значную шестнадцатеричную строку в кавычках, представляющую дайджест MD5 данных объекта. Для других объектов ETag может быть или не быть дайджестом MD5 данных объекта. Если ETag не является дайджестом MD5 данных объекта, он будет содержать один или несколько не шестнадцатеричных символов и / или будет состоять из менее 32 или более 32 шестнадцатеричных цифр.
Кажется, это описывает, как на самом деле вычисляется etag S3 и это сообщение о переполнении стека похоже, подразумевает то же самое: нельзя доверять Etag, чтобы он всегда был равен файлу MD5.
Итак - вот мои вопросы
- Вообще как сборщик файлов хранит файлы на s3? Используются ли составные почтовые запросы?
- Я вижу, что когда я делаю запрос HEAD, например, против
https://www.filepicker.io/api/file/<file handle>, я получаю обратно заголовок etag. Полученный мной etag действительно соответствует md5 загруженного мной файла. Заголовки возвращаются более или менее напрямую из S3? Или это действительно md5, рассчитанный программой filepicker, которому я могу доверять? - Возможно ли, чтобы явное выражение md5 было возвращено клиентам API средства выбора файлов? Например, когда мы отправляем файл POST, мы получаем обратно структуру JSON, включая URL-адрес файла и его размер. Можно ли сюда включить md5?
- Можно ли предоставить средству выбора файлов md5, который, в свою очередь, будет использоваться при публикации файлов на S3, чтобы мы могли получить сквозную проверку файлов?
