Всем привет. нужно сделать эндпоинт на который клиент может загружать

файлы, и потом эти файлы сразу грузить на амазоновский бакет. хотелось бы избежать загрузки файлов в память, так как они могут быть большие. но я вот почитал документацию aws sdk, и там пишут что при загрузке файла с инпут стрима в бакет нужно указывать content-length хедер. искал онлайн как достать размер файла из multipart запроса - ничего не нашел. в общем у меня 3 варианта - 1) возможно кто-нибудь здесь сталкивался с подобным и знает какой-то способ достать размер файла из мультипарт запроса. 2) сохранять файл временно на диске (локально на сервере), а уже потом прямо из файловой системы грузить в бакет. 3) забить на все это и просто не давать хедер, но тогда, судя по документации, aws sdk просто загрузит весь файл в буфер в памяти и сам посчитает его размер. как думаете, какой вариант лучше? спасибо

Лучше создать энжроинт, который будет делать signUrl

у мультипарт файла в джаве точно есть contentLength

не вариант, в рамках запроса будет не только аплоад, а еще куча всего

но это возможно лучший вариант

есть хедер в самом запросе, то мне нужен размер файла а не запроса

у амазона есть API позволяющий грузить файлы в бакет прямо из браузера. На бэке только подпись реализуется

Ну если вам его не передают, то только самому считать же :/

выше уже сказал, что загрузка в бакет это только маленькая часть логики запроса

эх, надеялся кто-нибудь какую-нибудь магию знате :с

нужно файл парсить на бэке?

нет, именно файл нужно только загрузить

тогда это не мешает тому, что я описал. А загрузка уйдет на клиент

тоже грузим файлы неизвестной длины в S3, используем комбинацию с apache-commons-fileupload вместе с https://github.com/alexmojaki/s3-stream-upload (обертка вокруг официального aws-sdk, там эту фичу очень неохотно пилят: https://github.com/aws/aws-sdk-java/issues/474).

мы тоже используем apache-commons-fileupload. вчера покопался в доках и сорсах, оказывается при превышении файлом установленного трешхолда в размере библиотека автоматически сохраняет его в темп папку (в треде человек как раз писал что в спринге так работает, но там как раз эта же либа под капотом). причем если в таком случае попытаться сохранить файл явно, то библиотека просто переименует уже существующий файл (само собой если сорс и таргет в одном логическом диске), и накакого копирования не произойдет. но если нужно избежать сохранения файла и стримить данные напрямую, то хз как это сделать, похоже стандартного решения нету. но в моем кейсе пока и так сойдет

я же говорил)

можно попробовать стримить через piped стримы

а вот из браузера таких проблем нет ;)

разница только в том что спринг по дефолту ставит этот трешхолд на 0, то есть все файлы без исключений будут сразу на диске сохраняться

можете линкануть какой-то ресурс где об этом почитать можно, если несложно? сомневаюсь что мне подойдет, но все же интересно. или хотя бы как это дело гуглить

кажется, вот что-то похожее https://aws.amazon.com/blogs/compute/uploading-to-amazon-s3-directly-from-a-web-or-mobile-application/

очень благодарен. вообще звучит интересно. но мне вот нужно после загрузки файла на с3 вызвать еще дополнительную логику. думаю покопать в сторону каких-то ивентов в с3, типа по загрузке файла с3 тригерит какой-то ивент, который дергает логику на сервере

так можно после загрузки с фронта на бэк тыкнуть. Или по крону проверять наличие на s3

фронта в этой ситуации нет, это просто эндпоинт который будет другими приложениями вызываться

Мы писали прокси аплоадер который стримил на с3 напрямую на голанге и роутили по контент тайпу на них внутри кластера У вас есть два стула - либо изворачиваться и проксировать через себя (любыми средствами - кэшируя, записывая на диск) Либо использовать пресигнед урл и подписываться на бэкенде на события бакета (и по ним писать мету куда нибудь)

а они сами в s3 не могут залить? То же самое может клиент делать

там кроме файла есть еще параметры всякие. да и не знаю че там с пермишенами, сомневаюсь что у этих приложений есть прямой доступ к нашим бакетам. но я поспрашиваю

С пресигнедом вам не надо доступов давать, будут индивидуальные подписанные ссылки на каждую загрузку

почитайте линк. Там с безопасностью все продумано. Выдается специальное разрешение под write-only. Параметры можно передать вашему серверу уже через http

это прям хорошо

оно еще и распределением нагрузки хорошо

Мы используем fileupload в таком виде, что просто достаем голый InputStream через FileItemIterator (cм. https://commons.apache.org/proper/commons-fileupload/streaming.html)

рассматривал этот вариант, но у нашей прослойки над aws sdk нету метода который принимает инпут стрим, только файлы 🤡🤡🤡