«Прикладные системы на основе web-программирования»

Common Gateway Interface

Спецификация CGI, разработанная в NCSA, впервые была включена в свободнораспространяемые серверы NCSA. В то время это был колоссальный шаг вперед по сравнению с механизмами подключения внешних программ к серверу CERN. Разработчики сайтов получили простую возможность включить в свои страницы практически все локальные информационные ресурсы организации и таким образом обеспечить удаленный доступ к ним по сети.
Интересно, что параллельно с появлением спецификации CGI в стандарт HTML были введены формы. Собственно, формы и CGI - две стороны одной медали. И формы, и CGI были первоначально предназначены для обмена данными между прикладной программой и программой просмотра гипертекстовых страниц. При этом CGI предполагалось использовать не только в Web, но и для расширения возможностей других информационных технологий Internet.
Вот как в данном случае выглядит взаимодействие с сервером. Программа-браузер отправляет запрос серверу. В качестве URL в запросе используется адрес CGI-скрипта. При этом данные могут содержаться как в самой спецификации URL (компонент пути в схеме HTTP), так и в теле HTTP-сообщения (в случае использования методов POST или PUT). Сервер определяет тип URL, то есть то, что это именно скрипт, а не HTML-страница, либо по маршрутному имени ресурса (обычно - каталог cgi-bin), либо по расширению имени файла (обычно *.cgi). После этого сервер порождает процесс-потомок, передает в него значения переменных окружения, которые порождаются в соответствии со спецификацией CGI, загружает CGI-скрипт и передает ему управление. CGI-скрипт анализирует окружение; если необходимо, считывает данные из потока стандартного ввода, который организован сервером; производит обработку информации, определенную алгоритмом, реализованным в скрипте; и возвращает результат вычислений через свой стандартный вывод в форме, определенной в спецификации CGI. После этого процесс, в котором исполнялся скрипт, завершается. Взаимодействие браузера, сервера и скрипта в этом случае носит разовый характер и по своей природе не ориентировано на длительный диалог, т. е. сессию.
Перечислим основные преимущества такого решения: простота, независимость, выполнение в отдельном адресном пространстве, открытый стандарт, архитектурная независимость.
Простота заключается в том, что прикладному программисту, знакомому с основами программирования для ОС Unix, не требуется изучать каких-либо еще спецификаций. Все взаимодействие прикладной программы с сервером основывается на знании окружения, в котором функционирует программа, и правил ввода/вывода данных через стандартные ввод/вывод. Фактически надо просто, используя функцию getenv(), получить значение переменной окружения и вывести всю информацию через стандартные функции форматной печати - printf(). Если программа работает в режиме обмена данными через командную строку и стандартный вывод, то для ее подключения к серверу необходимо затратить минимум усилий. Сложнее подключать программы с развитым графическим пользовательским интерфейсом, но обычно в "грамотно" написанных программах интерфейсный модуль выделен и допускает простую замену.
Независимость подразумевает возможность написания программы на любом из универсальных языков программирования или скриптов на языках программирования сценариев, например командных языках. В этом случае абсолютно не имеет значения язык, на котором написан сервер. Взаимодействие, организованное через переменные окружения, командную строку и стандартные ввод/вывод, осуществляется всегда одинаково в конкретной операционной среде.
С точки зрения влияния прикладной программы на операционную среду или на сервер спецификация CGI также выглядит безупречно. Скрипт запускается в своем адресном пространстве и никак не влияет на другие компоненты, которые система исполняет одновременно со скриптом.
Спецификация CGI является открытым стандартом. Это означает, что скрипт, написанный для одного сервера, будет прекрасно работать и с другими серверами, поддерживающими спецификацию. В этом легко может убедиться любой, кто пожелает мигрировать, скажем, с сервера NCSA или CERN на Apache или обратно. Единственное исключение составляют продукты Microsoft. Но даже в этом случае, как правило, переносимость скриптов от одного сервера к другому сохраняется.
Спецификация CGI не зависит от платформы. Действительно, в любой операционной среде есть переменные окружения и понятия стандартных потоков ввода, вывода и ошибок. В частности, это позволяет выполнять скрипты, разработанные для ОС Unix, в среде MS-DOS. Типичным примером является скрипт Imagemap. Любопытно, что при переносе его на MS-DOS сохранилась даже ошибка с обработкой конца файла при просмотре описаний разбиения графического образа на фрагменты.
Естественно, что при всех своих несомненных достоинствах CGI имеет и недостатки. Главным из них является низкая скорость реакции на запрос пользователя. В то время, когда NCSA ввел в обращение CGI, количество обращений к сайту было невелико. О масштабах AltaVista или Lycos не могло быть и речи. В этих условиях можно было пренебречь скоростью в угоду простоте и надежности. Главной причиной медленного отклика является порождение полноценного процесса при обращении к скрипту. Это тем более выглядит нелепо, если даже Apache для повышения своей "реактивности" при старте запускает сразу несколько серверов-потомков, ускоряющих обработку запросов пользователей. Если при этом через данных потомков обращаются к CGI-скриптам, то весь выигрыш оказывается потерян.
Другим недостатком скриптов является тот факт, что использовать их можно только для ответа клиенту. Провести их обработку стандартными средствами сервера перед отправкой клиенту уже нельзя. Для этого приходится пользоваться отложенным обращением к результатам работы скрипта, которые предварительно помещаются в файл.