Pull to refresh

Comments 15

Можно запретить nginx буферидовать ответ от fcgi на диск (x-accel-buffering), чтобы избежать лишнего io. Но в этом случае в памяти будет висеть по экземпляру zip на клиента.

Я бы рекомендовал реализовать упаковку на каком-нибудь асинхронном фреймворке (node, tornado), тогда это будет не проблема.
запретить nginx буферидовать ответ от fcgi на диск (x-accel-buffering)
X-Accel-Buffering не для этого предназначен. Запрет кэширования на диск осуществляется директивой proxy_max_temp_file_size. А директива proxy_buffering и X-Accel-Buffering в значении off — это такой способ убить производительность.
В Linux есть проблемы с неблокирующим вводом-выводом из файлов. Параллелить оный придется все равно тредами или процессами.
А что будет если, например, вызвать/download.cgi?/etc или /download.cgi?/?
Не должна же запаковаться корневая директория с конфигами… Не вижу проверок на такие ситуации
верное замечание — исправил, спасибо!
смотрели, но хотелось чего-то попроще — без заморочек с контрольными суммами и с возможностью добавить свою логику, не зная C
плюс отдача директории целиком вроде не поддерживатся — нужно перечислять все файлы
По мне так это более удобный и управляемый вариант.
Почему бы не заменить вот это:
pushd "$homeDir" > /dev/null

простым cd?

А popd совсем удалить?
Верно ли я понимаю, что любой юзер, обладающий любым доступом на сайт, может дописать к /download.cgi?имя-любой-директории, если он знает имя этой директории? Т.е. никакого разграничения по правам доступа к папкам у вас нет?
upd: имею в виду, что все юзеры имеют доступ ко всем папкам внутри /storage/media/audio?
да, в /storage/media/audio хранятся только альбомы
Думаю, можно обойтись без fcgiwrap и перенести bash-скрипт на xinet.d

Как-то так
service ws
{
   port            = 8081
   socket_type     = stream
   wait            = no
   type = UNLISTED
   user            = www-data
   server          = /bin/bash
   server_args = /root/ws.sh
   log_on_success  += USERID
   log_on_failure  += USERID
   disable         = no
}

Есть небольшой закрытый сайт
и
но у нас обычные пользователи и для многих будет загадкой что делать с tar

Как-то не вяжется. Если количество пользователей ограничено, то сделать краткую инструкцию по распаковке .tar не должно составить труда.

p. s.: Как-то нехорошо на Хабре говорить про пиратские сайты. Нет?
Где я говорил про пиратские сайты? o_0
Зачем писать инструкцию по распаковке tar если можно сразу отдать zip и облегчить жизнь пользователю?
Sign up to leave a comment.

Articles