CGI - Common Gateway Interface
CGI - Common Gateway Interface
CGI - Common Gateway Interface является
стандартом интерфейса (связи)
внешней прикладной программы с
информационным сервером типа HTTP, Web
сервер.
Обычно гипертекстовые документы,
извлекаемые из WWW серверов,
содержат статические данные. С
помощью CGI можно создавать
CGI-программы, называемые шлюзами,
которые во взаимодействии с такими
прикладными системами, как система
управления базой данных,
электронная таблица, деловая
графика и др., смогут выдать на
экран пользователя динамическую
информацию.
Программа-шлюз запускается WWW
сервером в реальном масштабе
времени. WWW сервер обеспечивает
передачу запроса пользователя
шлюзу, а она в свою очередь,
используя средства прикладной
системы, возвращает результат
обработки запроса на экран
пользователя. Программа-шлюз может
быть закодирована на языках C/C++,
Fortran, Perl, TCL, Unix Schell, Visual Basic, Apple Script.
Как выполнимый модуль, она
записывается в поддиректорий с
именем cgi-bin WWW сервера.
Оригинал описания CGI интерфейса -
инструмента связи программы-шлюз с
WWW сервером находится в узле wist.ifmo.ru
.
Для передачи данных об
информационном запросе от сервера
к шлюзу, сервер использует
командную строку и переменные
окружения. Эти переменные
окружения устанавливаются в тот
момент, когда сервер выполняет
программу шлюза.
Запросы для
различных методов
Информация шлюзам передается в
следующей форме:
имя=значение&имя1=значение1&..,
где имя- имя переменной (из
оператора FORM,
например), и значение - ее реальное
значение. В зависимости от метода,
который используется для запроса,
эта строка появляется или как часть
URL (в случае метода GET),
или как содержимое HTTP
запроса (метод POST). В
последнем случае, эта информация
будет послана шлюзу в стандартный
поток ввода.
На файловый дескриптор
стандартного потока ввода
посылается CONTENT_LENGTH
байт. Так же сервер передает шлюзу CONTENT_TYPE (тип
передаваемых данных). Сервер не
обязан посылать символ конца файла
после отсылки CONTENT_LENGTH байт данных и
после того, как шлюз их прочитает.
Пример
Возьмем результат работы формы с
методом POST (METHOD="POST") в качестве
примера. Пусть получено 7 байт,
закодированных примерно так:
a=b&b=c.
В этом случае, сервер установит
значение CONTENT_LENGTH равным 7 и CONTENT_TYPE в
application/x-www-form-urlencoded. Первым символом
в стандартном потоке ввода для
шлюза будет "a", за которым
будет следовать остаток
закодированной строки.
Аргументы
командной строки
Шлюз в командной строке от
сервера получает:
- остаток URL после имени шлюза в
качестве первого параметра
(первый параметр будет пуст,
если присутствовало только имя
шлюза), и
- список ключевых слов в
качестве остатка командной
строки для скрипта поиска, или
- чередующиеся имена полей формы
с добавленным знаком равенства
(на четных позициях) и
соответствующих значений
переменных (на нечетных
позициях).
Ключевые слова, имена полей формы
и значения передаются
раскодированными (из HTTP URL формата
кодирования) и перекодированными в
соответствии с правилами
кодирования Bourne shell, так что шлюз в
командной строке получит
информацию в том виде, как она есть,
без необходимости осуществлять
дополнительные преобразования.
Запросы оператора FORM
Запросы оператора FORM
обрабатываются таким образом, что
каждый параметр, отвечающий за имя
поля, оканчивается знаком
равенства, а остаток представляет
собой значение этого параметра.
Если присутствует что либо после
имени скрипта (шлюза), то эта
информация передается в качестве
первого параметра. Иначе первый
параметр будет пуст.
Примеры:
/htbin/foo/x/y/z?name1=value1&name2=value2
вызывается как:
/.../foo /x/y/z name1= value1 name2= value2
а
/htbin/foo?name1=value1&name2=value2
вызывается как:
/.../foo '' name1= value1 name2= value2
CGI переменные
окружения
Следующие переменные окружения
не являются специфичными по типу
запросов и устанавливаются для
всех запросов.
- SERVER_SOFTWARE
- Название и версия
информационного сервера,
который отвечает на запрос (и
запускает шлюз). Формат:
имя/версия
- SERVER_NAME
- Имя хоста, на котором запущен
сервер, DNS имя, или IP адрес в том
виде, в котором он представлен
в URL.
- GATEWAY_INTERFACE
- Версия CGI спецификации на тот
момент, когда компилировался
сервер. Формат: CGI/версия
Следующие переменные окружения
являются специфичными для разных
запросов, и заполняются перед
вызовом шлюза:
- SERVER_PROTOCOL
- Имя и версия информационного
протокола, в котором пришел
запрос. Формат: протокол/версия
- SERVER_PORT
- Номер порта, на который был
послан запрос
- REQUEST_METHOD
- Метод, который был использован
для запроса. Для HTTP, это "GET", "HEAD", "POST", и т.д.
- PATH_INFO
- Дополнительная информация о
пути, которую передал клиент.
Другими словами, доступ к шлюзу
может быть осуществлен по
виртуальному пути, за которым
следует некоторая
дополнительная информация. Эта
информация передается в PATH_INFO.
- PATH_TRANSLATED
- Сервер передает
преобразованную версию PATH_INFO,
которая включает в себя путь,
преобразованный из
виртуального в физический.
- SCRIPT_NAME
- Виртуальный путь к шлюзу,
который должен выполняться,
используемый для получения URL.
- QUERY_STRING
- Информация, следующая за ? в URL,
к которому относится данный
шлюз. Это информация
представляет собой строку
запроса. Она не должна быть
декодирована никоим образом.
Вне зависимости от командной
строки эта переменная всегда
должна быть установлена при
наличии такой информации, .
- REMOTE_HOST
- Имя хоста, производящего
запрос. Если сервер не имеет
такой информации, он должен
установить REMOTE_ADDR, а это поле
оставить не установленным.
- REMOTE_ADDR
- IP адрес хоста, производящего
запрос.
- AUTH_TYPE
- Если сервер поддерживает
идентификацию пользователя, и
шлюз является защищенным от
постороннего доступа, этот
специфичный для протокола
метод идентификации
используется для проверки
пользователя.
- REMOTE_USER
- Используется в ситуациях,
аналогичных предыдущему
случаю, для хранения имени
пользователя.
- REMOTE_IDENT
- Если HTTP сервер поддерживает
идентификацию пользователя
согласно RFC 931, то эта
переменная будет содержать имя
пользователя, полученное от
сервера.
- CONTENT_TYPE
- Для запросов, которые содержат
дополнительную добавочную
информацию, такие как HTTP POST и PUT,
здесь содержится тип данных
этой информации.
- CONTENT_LENGTH
- Длина данных, которую передает
клиент.
В дополнение к этим, если запрос
содержит дополнительные поля
заголовка запроса, они помещаются в
переменные окружения с префиксом
HTTP_, за которым следует имя
заголовка. Любые символы '-' в
заголовке меняются на символы
подчеркивания '_'. Сервер может
исключить любые заголовки, которые
он уже обработал, такие как Authorization,
Content-type, и Content- length. Если необходимо,
сервер может исключить любые (или
вообще все) дополнительные поля
заголовка в случае, когда их
включение может привести к
превышению предела размера
переменных окружения. Примером
такой переменной может служить
переменная HTTP_ACCEPT, которая была
определена в спецификации CGI/1.0.
Другим примером может служить
заголовок User-Agent.
- HTTP_ACCEPT
- Список MIME типов, которые клиент
может обработать, как задано в
HTTP заголовках. Другие
протоколы должны получить эту
информацию из других мест (если
она им необходима). Каждый тип в
этом списке должен быть
отделен запятой согласно HTTP
спецификации. Формат:
тип/подтип, тип/подтип
- HTTP_USER_AGENT
- Просмотрщик, который
использует клиент для посылки
запроса. Общий формат:
программа/версия
библиотека/версия.
Основные
концепции
Шлюз осуществляет свой вывод в
стандартный поток вывода. Этот
вывод может представлять собой или
документ, сгенерированный шлюзом,
или инструкции серверу, где
получить необходимый документ.
Как правило, шлюз производит свой
вывод, который интерпретируется и
посылается обратно клиенту.
Преимущество этого подхода состоит
в том, что шлюз не должен посылать
полный HTTP/1.0 заголовок на каждый
запрос.
Заголовок
выходного потока
Для некоторых шлюзов может быть
необходимо избегать обработки
сервером их вывода, и общаться с
клиентом непосредственно. Для того,
чтобы отличить такие шлюзы от
остальных, CGI требует, чтобы их
имена начинались с префикса nph-. В
этом случае, на шлюзе лежит
ответственность за возвращение
клиенту синтаксически правильного
ответа.
Заголовки с
синтаксическим разбором
Вывод шлюза начинается с
маленького заголовка. Он содержит
текстовые строки, в том же формате,
как и в HTTP заголовке и завершается
пустой строкой (содержащей только
символ перевода строки или CR/LF).
Любые строки заголовка, не
являющиеся директивами сервера,
посылаются непосредственно
клиенту. В настоящий момент, CGI
спецификация определяет три
директивы сервера:
- Content-type
- MIME тип возвращаемого
документа.
- Location
- Это поле используется в случае,
когда необходимо указать
серверу, что возвращается не
сам документ, а ссылка на него.
Если аргументом является URL, то
сервер передаст клиенту указание
на перенаправление запроса. Если
аргумент представляет собой
виртуальный путь, сервер вернет
клиенту заданный этим путем
документ, как если бы клиент
запрашивал его непосредственно.
Эта директива используется для
задания серверу HTTP/1.0 строки-статус,
которая будет послана клиенту.
Формат: nnn xxxxx, где nnn - 3-х цифровой
статус-код, и xxxxx строка причины,
такая, как "Forbidden" (Запрещено).
Примеры
Предположим, имеется некоторый
текстовый конвертер в HTML. Когда он
оканчивает свою работу, он должен
произвести следующий вывод в
стандартный выходной поток:
--- начало вывода ---
Content-type: text/html
--- конец вывода ---
Теперь рассмотрим шлюз, который, в
некоторых случаях, должен выдать
документ /path/doc.txt с данного сервера,
как если бы он был непосредственно
востребован клиентом через
http://server:port/path/doc.txt. В это случае
вывод шлюза будет таков:
--- начало вывода ---
Location: /path/doc.txt
--- конец вывода ---
Наконец, предположим, что шлюз
возвращает ссылки на gopher сервер,
например на gopher://gopher.ncsa.uiuc.edu/. Вывод
шлюза будет следующий:
--- начало вывода ---
Location: gopher://gopher.ncsa.uiuc.edu/
--- конец вывода ---
Non-parsed headers
Допустим теперь, что у нас имеется
шлюз, который общается с клиентом
непосредственно. Как уже
отмечалось, его имя должно
начинаться с префикса nph- и он
должен возвращать допустимый HTTP
заголовок. В этом случае, если
доступ к шлюзу был осуществлен со
значением SERVER_PROTOCOL равным HTTP/1.0, его
вывод должен удовлетворять HTTP/1.0:
--- начало вывода ---
HTTP/1.0 200 OK
Server: NCSA/1.0a6
Content-type: text/plain
--- конец вывода ---
|
