1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.RUSSIAN

  • Re: =?utf-8?B?0JzQvtC90YLQuNGA0L7QstCw0YI=?= =?utf-8?B?0Ywg0YEg0L7QtNC9

    From Eugene Berdnikov@21:1/5 to Dmitrii Kashin on Sun Oct 13 18:10:01 2024
    On Sun, Oct 13, 2024 at 06:10:12PM +0300, Dmitrii Kashin wrote:
    > On 12 Oct 2024, at 19:23, Misha Ramendik <[email protected]> wrote:
    [...]
    > VPS-клиент это обычная VPS, а VPS-сервер это "HDD VPS", где много
    > медленного хранилища и мало процессора.

    Слишком абстрактно. Вопрос был, как ты с этим потом работаешь.
    Приведу пример. Одно дело -- если ты это скаченное добро потом сервишь
    через nginx какой-нибудь во внешку "как есть". Другое -- если ты это на
    торрентах, например, раздаёшь.
    Во втором случае у тебя софт работает с кусками файлов, и ему нужны такие
    вещи, например, как seek в произвольное место файла. И тогда тебе нужна
    полноценная ФС.
    В первом случае у тебя просто разок укачать, а потом раздавать в
    неизменном виде файлы целиком, и тогда лучшим выбором будет s3-хранилище.

    На vps/vds-хостингах обычные файловые системы, поддерживающие seek(2),
    а для современых ssd-дисков стоимость seek() ничтожно мала по сравнению
    с передачей данных.
    --
    Eugene Berdnikov

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eugene Berdnikov@21:1/5 to Victor Wagner on Mon Oct 14 11:10:01 2024
    On Mon, Oct 14, 2024 at 11:02:17AM +0300, Victor Wagner wrote:
    В Mon, 14 Oct 2024 04:05:56 +0100
    Misha Ramendik <[email protected]> пишет:

    авторизации. Я высылаю линк человеку, он по этому линку нажимает
    кнопку и заливает файл, линк перестаёт работать. Если можно как-то
    обрабатывать заливаемое CGI по кусочкам (и выдавать при этом юзеру
    progress), то я пожалуй понимаю как это реализовать, но это пока
    "если".

    Проще считать что в тот момент когда у тебя запустился скрипт и получил
    multipart/form-data, у тебя уже весь файл на сервере.

    Проще, но при таком подходе progress-bar никак не сделать.

    И если бы данные от клиента всегда целиком выкачивались бы на сервер,
    то это означало бы, что лимит на upload не работает. И это была бы дырка
    для DoS-a. Обработчик должен выкачивать небольшую часть тела запроса,
    делать разборку заголовков (включая Content-type: multipart/form-data),
    а затем вычитывать сокет/пайп до тех пор, пока не будет превышен лимит.
    При превышении нужно выдать клиенту ошибку и закрыть сокет/пайп.
    --
    Eugene Berdnikov

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eugene Berdnikov@21:1/5 to Victor Wagner on Mon Oct 14 11:40:01 2024
    On Mon, Oct 14, 2024 at 12:19:57PM +0300, Victor Wagner wrote:
    Проще считать что в тот момент когда у тебя запустился скрипт и
    получил multipart/form-data, у тебя уже весь файл на сервере.

    Проще, но при таком подходе progress-bar никак не сделать.

    Поэтому не надо увлекатсья украшательством и делать прогресс-бары.

    Согласен. Тем более что простого способа делать прогресс-бары
    для web uploads не видно. Ну, я лично не знаю...

    И если бы данные от клиента всегда целиком выкачивались бы на сервер,
    то это означало бы, что лимит на upload не работает. И это была бы
    дырка для DoS-a.

    Да, конечно. Но скорее всего это решается лимитом на размер тела
    запроса на уровне конфигурации веб-сервера

    Тоже согласен. Однако лучше когда лимит и там, и там.

    Современные web-сервера не доверяют пользовательским обработчикам. С
    недавних пор в apache не доверяют даже Content-Length,

    Далеко не все браузеры не выставляют этот Content-Length при аплоаде.
    Как-то я проверял на этот счёт Firefox и удивился, что заголовка нет.
    --
    Eugene Berdnikov

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)