13 513
правок
Изменения
м
PSGI — PSGI — Perl-реализация питонячьего [http://wsgi.readthedocs.org/ WSGI. «Низкоуровневый» интерфейс взаимодействия тривиален:
== Standalone ==
Альтернативой встраиванию интерпретатора в процесс HTTP-сервера является запуск собственного HTTP-сервера, рассчитанного на расположение за обратным прокси (reverse proxy) — [http://httpd.apache.org/docs/2.0/mod/mod_proxy.html mod_proxy] Апача, [http://nginx.ru/ nginx]'ом, или [http://www.squid-cache.org/ Squid]'ом — в качестве фронтенда. Так делают, например, [http://www.mortbay.org/ Jetty] (Java) и [http://www.zope.org/ Zope] (Python). Это работает точно так же, как обработка запросов внутри сервера, только запросы отправляются другому HTTP-серверу.
У такого подхода — использования HTTP вместо встраивания интерпретатора в сервер, или вариаций на тему CGI — есть несколько приятных преимуществ. Фронтенд может балансировать и распределять по нескольким серверам нагрузку одновременно с передачей запроса, причём для этого существует множество готовых качественных инструментов. Работа администраторов упрощается, потому что конфигурация фронтенда для передачи запроса разным приложениям идентична, а сами приложения могут быть запущены под любым системным пользователем, на другом сервере, в jail’е, виртуальной машине, за аппаратным firewall’ом или внутри какой-нибудь другой системы безопасности. При отладке разработчик может взаимодействовать напрямую со своим приложением без необходимости запускать отдельный HTTP-сервер. Потребление памяти сокращается засчёт изоляции каждого придожения в своём наборе процессов.
Кроме того, в этом случае приложение свободно от накладных расходов веб-сервера — для того же mod_perl’а генерация страниц без кэширования (но и без особых изысканий) за 1.5 мс почти «фантастика».
=== <s>LWP (HTTP::Daemon)</s> ===
{{CPAN|LWP}} (''libwww-perl'') — библиотека для создания как клиентов, так и серверов, полностью совместимых со спецификацией HTTP/1.1, на чистом Perl’е.
В качестве единственной готовой, пусть и исключительно простой, платформы, исповедующей идеологию получения запросов в форме HTTP::Request и ответа HTTP::Response’ами можно рассмотреть {{CPAN|HTTP::Server::Brick}}, построенный на основе HTTP::Daemon.
Плюсы:
* Очень логичная и правильная '''идея''' программного интерфейса — {{CPAN|HTTP::Request}}, {{CPAN|HTTP::Response}}, {{CPAN|HTTP::Body}} и т. п. (HTTP::Body, кстати, использует {{CPAN|Catalyst}})…
Минусы:
* …Увы, оставшаяся без полной реализации.
* Главный минус в том, что LWP в качестве основы HTTP-сервера не использует, видимо, '''практически никто'''. Посему, сколь логичным бы ни выглядел сервер, получающий на вход HTTP::Request и отвечающий HTTP::Response’ами, реально готовых наработок для такого подхода фактически нет. Например, нет ничего похожего на удобный Apache2::Request, с готовыми функциями для доступа к запросу, разобранному на URI, параметры POST, заголовки и куки.
Нет описания правки
* Поразительное качество: невозможно получить список ''всех'' HTTP-заголовков, присутствующих в запросе, а можно лишь считывать их по одному. Остаётся только применять [{{SVN|vitalif/trunk/scripts/nginx.xs.diff}} патч к src/http/modules/perl/nginx.xs].
* Отсутствие поддержки CGI среды внутри ngx_http_perl_module, наподобие mod_perl апача.
== Standalone ==
Альтернативой встраиванию интерпретатора в процесс HTTP-сервера является запуск собственного HTTP-сервера, рассчитанного на расположение за обратным прокси (reverse proxy) — [http://httpd.apache.org/docs/2.0/mod/mod_proxy.html mod_proxy] Апача, [http://nginx.ru/ nginx]'ом, или [http://www.squid-cache.org/ Squid]'ом — в качестве фронтенда. Так делают, например, [http://www.mortbay.org/ Jetty] (Java) и [http://www.zope.org/ Zope] (Python). Это работает точно так же, как обработка запросов внутри сервера, только запросы отправляются другому HTTP-серверу.
У такого подхода — использования HTTP вместо встраивания интерпретатора в сервер, или вариаций на тему CGI — есть несколько приятных преимуществ. Фронтенд может балансировать и распределять по нескольким серверам нагрузку одновременно с передачей запроса, причём для этого существует множество готовых качественных инструментов. Работа администраторов упрощается, потому что конфигурация фронтенда для передачи запроса разным приложениям идентична, а сами приложения могут быть запущены под любым системным пользователем, на другом сервере, в jail’е, виртуальной машине, за аппаратным firewall’ом или внутри какой-нибудь другой системы безопасности. При отладке разработчик может взаимодействовать напрямую со своим приложением без необходимости запускать отдельный HTTP-сервер. Потребление памяти сокращается засчёт изоляции каждого придожения в своём наборе процессов.
Кроме того, в этом случае приложение свободно от накладных расходов веб-сервера — для того же mod_perl’а генерация страниц без кэширования (но и без особых изысканий) за 1.5 мс почти «фантастика».
=== {{CPAN|PSGI}}/{{CPAN|Plack}} ===
Можно смело сказать, что {{CPAN|PSGI}}/[http://plackperl.org Plack] — — самый современный и удобный интерфейс для Perl веб-приложений.
* Приложение = функция.
* На входе 1 хешреф «окружения», в который включаются, во-первых, параметры, аналогичные %ENV в CGI (REQUEST_URI, PATH_INFO и ти т. пп.)…
* …а во-вторых, некоторые PSGI-специфичные ключи, например, «input», содержащий входной поток.
* На выходе массив из 3-х элементов: численный статус ответа, массив заголовков в виде [ Header => Value, Header => Value, … ] и текст ответа.
Однако без дополнительных обёрток такой интерфейс неудобен, поэтому есть вполне себе удобный {{CPAN|Plack}}, имеющий вполне вменяемый интерфейс — интерфейс — например, Plack::Request->parameters возвращает в виде хеша все GET и POST параметры, Plack::Request->cookies — cookies — хеш кукисов и ти т. пп. Это — Это — в отличие от модулей типа CGI и PCGI, в которых параметры и куки нужно читать по отдельности через param() и cookie().
Плюсы:
Минусы:
* Разве что отсутствие совместимости со «старыми» приложениями — приложениями — то есть, нельзя просто обернуть CGI скрипт в функцию и превратить его таким образом в PSGI.
* (Не проверено) возможно, в PSGI серверах отсутствует поддержка перезагрузки модулей.
* В остальном, похоже, всё хорошо.
=== HTTP::Server::Simple ===
** Читает из стандартного ввода запрос и заголовки она по 1 символу функцией [http://perldoc.perl.org/functions/sysread.html sysread()], что весьма негативно сказывается на производительности.
** В качестве разделителя строк, согласно всем стандартам, при обмене данными по сети, должно выступать сочетание CR-LF в платформо-независимом варианте: «\015\012». Тем не менее, функции HTTP::Server::Simple используют просто «\n», что тоже работает, но не является идеально переносимым вариантом.
=== <s>LWP (HTTP::Daemon)</s> ===
{{CPAN|LWP}} (''libwww-perl'') — библиотека для создания как клиентов, так и серверов, полностью совместимых со спецификацией HTTP/1.1, на чистом Perl’е.
В качестве единственной готовой, пусть и исключительно простой, платформы, исповедующей идеологию получения запросов в форме HTTP::Request и ответа HTTP::Response’ами можно рассмотреть {{CPAN|HTTP::Server::Brick}}, построенный на основе HTTP::Daemon.
Плюсы:
* Очень логичная и правильная '''идея''' программного интерфейса — {{CPAN|HTTP::Request}}, {{CPAN|HTTP::Response}}, {{CPAN|HTTP::Body}} и т. п. (HTTP::Body, кстати, использует {{CPAN|Catalyst}})…
Минусы:
* …Увы, оставшаяся без полной реализации.
* Главный минус в том, что LWP в качестве основы HTTP-сервера не использует '''практически никто'''. Посему, сколь логичным бы ни выглядел сервер, получающий на вход HTTP::Request и отвечающий HTTP::Response’ами, реально готовых наработок для такого подхода фактически нет. Например, нет ничего похожего на удобный Apache2::Request, с готовыми функциями для доступа к запросу, разобранному на URI, параметры POST, заголовки и куки.
== Заключение ==
