Общий интерфейс шлюза

Официальный логотип CGI из анонса спецификации.

В вычислительной технике Common Gateway Interface ( CGI ) — это спецификация интерфейса, которая позволяет веб-серверам выполнять внешнюю программу для обработки пользовательских запросов HTTP или HTTPS .

Такие программы часто пишутся на языке сценариев и обычно называются CGI-скриптами , но они могут включать в себя скомпилированные программы.

Типичный вариант использования происходит, когда веб-пользователь отправляет веб-форму на веб-страницу, использующую CGI. Данные формы отправляются на веб-сервер в HTTP-запросе с URL-адресом, обозначающим CGI-скрипт. Затем веб-сервер запускает сценарий CGI в новом компьютерном процессе , передавая ему данные формы. CGI-скрипт передает свои выходные данные, обычно в форме HTML , на веб-сервер, а сервер передает их обратно браузеру в качестве ответа на запрос браузера.

Разработанный в начале 1990-х годов, CGI был самым ранним доступным методом, позволяющим сделать веб-страницу интерактивной. В связи с необходимостью запускать CGI-скрипты в отдельном процессе каждый раз при поступлении запроса от клиента были разработаны различные альтернативы.

История

В 1993 году команда Национального центра суперкомпьютерных приложений (NCSA) написала спецификацию для вызова исполняемых файлов командной строки в списке рассылки www-talk. Другие разработчики веб-серверов переняли его, и с тех пор он стал стандартом для веб-серверов. В ноябре 1997 года рабочая группа под председательством Кена Коара начала работу над более формальным определением компьютерной графики, данным NCSA. Результатом этой работы стал RFC 3875, в котором указана версия CGI 1.1. В RFC особо упоминаются следующие участники:

• Роб МакКул (автор веб-сервера HTTPd NCSA )
• Джон Фрэнкс (автор веб-сервера GN)
• Ари Луотонен (разработчик веб-сервера httpd CERN )
• Тони Сандерс (автор веб-сервера Plexus)
• Джордж Филлипс (сопровождающий веб-сервера в Университете Британской Колумбии)

Исторически программы CGI часто писались с использованием языка программирования C. RFC 3875 «Общий интерфейс шлюза (CGI)» частично определяет CGI с использованием C, говоря, что переменные среды «доступны с помощью библиотечной процедуры getenv() или переменной environ».

Название CGI пришло из первых дней существования Интернета, когда веб-мастера хотели подключить устаревшие информационные системы, такие как базы данных, к своим веб-серверам. Программа CGI выполнялась сервером и обеспечивала общий «шлюз» между веб-сервером и устаревшей информационной системой.

Цель

Традиционно веб-сервер имеет каталог , который обозначается как коллекция документов, то есть набор файлов, которые можно отправлять в веб-браузеры, подключенные к серверу. Например, если веб-сервер имеет полное доменное имя www.example.com, а его коллекция документов хранится по адресу /usr/local/apache/htdocs/ в локальной файловой системе ее ( корень документа ), тогда веб-сервер ответит на запрос http://www.example.com/index.html отправив в браузер копию файла /usr/local/apache/htdocs/index.html (если он существует).

Для страниц, создаваемых «на лету», серверное программное обеспечение может откладывать запросы к отдельным программам и передавать результаты запрашивающему клиенту (обычно веб-браузеру, который отображает страницу конечному пользователю).

Такие программы обычно требуют указания некоторой дополнительной информации вместе с запросом, например строк запроса или файлов cookie . И наоборот, по возвращении сценарий должен предоставить всю информацию, необходимую HTTP для ответа на запрос: статус HTTP запроса, содержимое документа (если доступно), тип документа (например, HTML, PDF или обычный текст). и так далее.

Изначально не существовало стандартизированных методов обмена данными между браузером, HTTP-сервером, с которым он обменивался данными, и сценариями на сервере, которые должны были обрабатывать данные и в конечном итоге возвращать результат браузеру. В результате между различными вариантами HTTP-серверов существовала взаимная несовместимость, что подрывало переносимость скриптов .

Осознание этой проблемы привело к определению того, как должен осуществляться обмен данными, что привело к развитию CGI. которое соответствует спецификации CGI, известны как сценарии CGI , даже если на самом деле они могут быть написаны на языке без сценариев, таком как C. Программы, генерирующие веб-страницы, вызываемые серверным программным обеспечением ,

Спецификация CGI была быстро принята и продолжает поддерживаться всеми известными пакетами HTTP-серверов, такими как Apache , Microsoft IIS и (с расширением) node.js. серверами на базе

Раннее использование сценариев CGI заключалось в обработке форм. В начале HTML формы HTML обычно имели атрибут «действие» и кнопку, обозначенную как кнопка «отправить». При нажатии кнопки отправки URI, указанный в атрибуте «action», будет отправлен на сервер вместе с данными из формы, отправленными в виде строки запроса. Если в «действии» указан сценарий CGI, то сценарий CGI будет выполнен, а сценарий, в свою очередь, создаст HTML-страницу.

Развертывание

Веб-сервер, поддерживающий CGI, можно настроить для интерпретации URL-адреса , который он служит ссылкой на сценарий CGI. Общее соглашение заключается в том, чтобы иметь cgi-bin/ каталог в основании дерева каталогов и рассматривать все исполняемые файлы в этом каталоге (и никакие другие, в целях безопасности) как сценарии CGI. Когда веб-браузер запрашивает URL-адрес, указывающий на файл в каталоге CGI (например, http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string), то вместо того, чтобы просто отправлять этот файл ( /usr/local/apache/htdocs/cgi-bin/printenv.pl) в веб-браузер, HTTP-сервер запускает указанный сценарий и передает выходные данные сценария в веб-браузер. То есть все, что сценарий отправляет на стандартный вывод , передается веб-клиенту, а не отображается в окне терминала, в котором запустился веб-сервер. Другое популярное соглашение — использование расширений имен файлов ; например, если сценариям CGI постоянно присваивается расширение .cgi, веб-сервер можно настроить для интерпретации всех таких файлов как сценариев CGI. Хотя это удобно и требуется для многих готовых сценариев, оно открывает сервер для атаки, если удаленный пользователь может загрузить исполняемый код с соответствующим расширением.

Спецификация CGI определяет, как дополнительная информация, передаваемая вместе с запросом, передается сценарию. Веб-сервер создает подмножество переданных ему переменных среды и добавляет сведения, относящиеся к среде HTTP. Например, если к URL-адресу сразу после имени скрипта добавляются косая черта и дополнительные имена каталогов (в этом примере: /with/additional/path), то этот путь сохраняется в PATH_INFO переменная среды перед вызовом сценария. Если параметры передаются в скрипт через HTTP-запрос GET (к URL-адресу добавляется вопросительный знак, за которым следуют пары параметр=значение; в примере: ?and=a&query=string), то эти параметры сохраняются в QUERY_STRING переменная среды перед вызовом сценария. запроса Тело HTTP-сообщения , например параметры формы, отправленные через запрос HTTP POST сценария , передаются на стандартный ввод . Затем сценарий может прочитать эти переменные среды или данные из стандартного ввода и адаптироваться к запросу веб-браузера.

Использование

CGI часто используется для обработки входной информации пользователя и получения соответствующего вывода. Примером программы CGI является реализация вики-файла . Если пользовательский агент запрашивает имя записи, веб-сервер выполняет программу CGI. Программа CGI извлекает источник страницы этой записи (если он существует), преобразует его в HTML и печатает результат. Веб-сервер получает выходные данные программы CGI и передает их пользовательскому агенту. Затем, если пользовательский агент нажимает кнопку «Редактировать страницу», программа CGI заполняет HTML-код. textarea или другой элемент управления редактированием содержимого страницы. Наконец, если пользовательский агент нажимает кнопку «Опубликовать страницу», программа CGI преобразует обновленный HTML в исходный код страницы этой записи и сохраняет его.

Безопасность

Программы CGI по умолчанию запускаются в контексте безопасности веб-сервера. При первом представлении ряд примеров сценариев был предоставлен вместе со справочными дистрибутивами веб-серверов NCSA, Apache и CERN, чтобы показать, как можно закодировать сценарии оболочки или программы на языке C для использования нового CGI. Одним из таких примеров сценария была программа CGI под названием PHF, реализовавшая простую телефонную книгу.

Как и ряд других сценариев того времени, этот сценарий использовал функцию: escape_shell_cmd(). Предполагалось, что функция очистит свой аргумент, полученный от пользовательского ввода, а затем передаст его оболочке Unix для запуска в контексте безопасности веб-сервера. Сценарий неправильно очищал весь ввод и позволял передавать в оболочку новые строки, что фактически позволяло запускать несколько команд. Результаты этих команд затем отображались на веб-сервере. Если контекст безопасности веб-сервера позволяет это, злоумышленники могут выполнить вредоносные команды.

Это был первый широко распространенный пример нового типа веб-атаки, называемого внедрением кода , когда необработанные данные веб-пользователей могли привести к выполнению кода на веб-сервере. Поскольку пример кода был установлен по умолчанию, атаки были широко распространены и привели к появлению ряда рекомендаций по безопасности в начале 1996 года.

Альтернативы

Для каждого входящего HTTP-запроса веб-сервер создает новый процесс CGI для его обработки и уничтожает процесс CGI после обработки HTTP-запроса. Создание и уничтожение процесса может быть дорогостоящим: потреблять время ЦП и ресурсы памяти больше, чем фактическая работа по генерации выходных данных процесса, особенно когда программу CGI все еще необходимо интерпретировать виртуальной машиной. При большом количестве HTTP-запросов результирующая рабочая нагрузка может быстро перегрузить веб-сервер.

связанные Вычислительные затраты, с созданием и уничтожением процессов CGI, можно уменьшить с помощью следующих методов:

• Программы CGI, предварительно скомпилированные в машинный код , например, предварительно скомпилированные из программ C или C++ , а не программы CGI, выполняемые интерпретатором, например программы Perl , PHP или Python .
• Расширения веб-сервера, такие как модули Apache (например, mod_perl, mod_php и mod_python), подключаемые модули NSAPI и подключаемые модули ISAPI , которые позволяют длительным процессам приложений обрабатывать более одного запроса и размещаться на веб-сервере.
• FastCGI , SCGI и AJP , которые позволяют долго выполняющимся прикладным процессам обрабатывать более одного запроса, размещаемого на внешнем сервере; т.е. отдельно от веб-сервера. Каждый процесс приложения прослушивает сокет; веб-сервер обрабатывает HTTP-запрос и отправляет его через другой протокол (FastCGI, SCGI или AJP) в сокет только для динамического контента, тогда как статический контент обычно обрабатывается непосредственно веб-сервером. Этот подход требует меньшего количества прикладных процессов, поэтому потребляет меньше памяти, чем подход с расширением веб-сервера. И в отличие от преобразования прикладной программы в расширение веб-сервера, прикладные программы FastCGI, SCGI и AJP остаются независимыми от веб-сервера.
• Jakarta EE запускает Jakarta Servlet приложения в веб-контейнере для обслуживания динамического контента и, при необходимости, статического контента, что заменяет накладные расходы на создание и уничтожение процессов гораздо меньшими накладными расходами на создание и уничтожение потоков . Он также предоставляет программисту доступ к библиотеке, входящей в состав Java SE , на которой основана используемая версия Jakarta EE.
• Автономный HTTP-сервер
• Интерфейс шлюза веб-сервера (WSGI) — это современный подход, написанный на языке программирования Python . Это определено PEP 3333. и реализуется с помощью различных методов, таких как mod_wsgi (модуль Apache), веб-сервер Gunicorn (между Nginx и скриптами/фреймворками, такими как Django), UWSGI и т. д.

Оптимальная конфигурация любого веб-приложения зависит от особенностей приложения, объема трафика и сложности транзакции; эти компромиссы необходимо проанализировать, чтобы определить наилучшую реализацию для данной задачи и бюджета времени. Веб-фреймворки предлагают альтернативу использованию сценариев CGI для взаимодействия с пользовательскими агентами.

См. также

• CGI.pm - модуль Perl для программирования веб-приложений Common Gateway Interface (CGI). Страницы, отображающие описания викиданных в качестве резервного варианта.
• Интерфейс шлюза DOS — графический веб-браузер для DOS и Linux. Страницы с краткими описаниями целей перенаправления.
• Интерфейс шлюза веб-сервера Perl — инфраструктура веб-приложений. Страницы, отображающие описания викиданных в качестве запасного варианта.
• Rack (интерфейс веб-сервера) — спецификация API для веб-приложений на языке программирования Ruby.
• Включения на стороне сервера — интерпретируемый язык сценариев на стороне сервера.

Внешние ссылки

• Изобретение компьютерной графики
• Программирование CGI 101: Изучите CGI сегодня! , учебник CGI