Представьте себе, что вы создаете динамический сайт на выбранном вами языке программирования.
Когда пользователь заходит на ваш сайт, он делает запрос на http://name-of-your-site.com, и он передает его вашему серверу.
Когда запрос поступает на порт 80, он собирается вашим HTTP-сервером, который, вероятно, является Apache, но может быть LightHttpd или любым другим HTTP-сервером. Это позволит получить запрос и решить, что с ним делать.
Теперь, представляя себе, что ваш сайт написан на питоне, он будет где-то храниться в виде кучки .py-файлов, и поэтому запрос нужно передать во время выполнения питона с инструкциями, какой файл запускать и куда возвращать вывод из этого файла. Это роль mod_python - принимать запросы от сервера и передавать их во время выполнения. Большинство модов также работают с пулом потоков - предположим, что в течение минуты у вас будет двадцать запросов, если каждый из них будет передан на исполнение python простым способом, то у вас будет двадцать питоновских потоков, которые все запустятся, запустятся вместе, а затем умрут по мере того, как процесс будет завершен. Обычно моды Apache поддерживают несколько потоков, чтобы сэкономить время на запуске и просто передать новые запросы в один из существующих потоков, так что после завершения одного запроса он будет передан интерфейсом другому. Контейнеры CGI выполняют одну и ту же работу слабовыраженным образом, причина, по которой вы можете выбрать один из них вместо другого, скорее всего, связана с тем, какой HTTP-сервер вы используете (mod_python предназначен для Apache, Например, что-то вроде FastCGI больше используется в LightHttpd ) и в соображениях производительности. Если вы используете что-то вроде FastCGI, то вам потенциально понадобится второй уровень интерфейса между контейнером CGI и языком программирования.
Так что слои, с которыми вы работаете, выглядят немного похоже:
HTTP Server-> CGI Layer -> Programming Language Runtime -> your code
Apache -> mod_python -> Python Runtime -> index.py
LightHttpd -> FastCGI+python_cgi -> Python Runtime -> index.py
Очевидно, я использовал Python в качестве примера здесь, но вы можете найти эквивалентные моды и контейнеры cgi для большинства распространенных языков (и многих эзотерических), а стек Http, с которым вы работаете, будет в большинстве случаев похож.
.Короткий ответ на вопрос о названии: Да.
См. http://hackage.haskell.org/package/cgi
Network.cgi
Простая библиотека для написания программ CGI. См. . http://hoohoo.ncsa.uiuc.edu/cgi/interface.html для спецификации CGI.
Вот простой пример, включающий в себя обработку ошибок (не то, чтобы много чего можно было бы сделать Ошибка в Hello World)
import Network.CGI
cgiMain :: CGI CGIResult
cgiMain = output "Hello World!"
main :: IO ()
main = runCGI (handleErrors cgiMain)
Что касается интеграции частей, то
CGI - это протокол программирования и интерфейс между веб-сервером и некоторой внешней программой, обменивающийся стандартными входными и выходными данными и переменными окружения.
Вам нужен веб-сервер, который поддерживает CGI (большинство поддерживает), и вы должны настроить сервер так, чтобы для некоторых специальных запросов (например, URL с каким-либо специальным расширением файла) он вызывал CGI-программу. Для веб-сервера Apache смотрите http://httpd.apache.org/docs/2.0/howto/cgi.html