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

Поскольку гипертекст статичен по своей природе, веб-страница не может непосредственно взаимодействовать с пользователем. До появления JavaScript , не было иной возможности отреагировать на действия пользователя, кроме как передать введенные им данные на веб-сервер для дальнейшей обработки. В случае CGI эта обработка осуществляется с помощью внешних программ и скриптов, обращение к которым выполняется через стандартизованный (см. RFC 3875: CGI Version 1.1) интерфейс - общий шлюз. Упрощенная модель, иллюстрирующая работу CGI, приведена на рис. 1.

Как работает CGI?

Обобщенный алгоритм работы через CGI можно представить в следующем виде:

1. Клиент запрашивает CGI-приложение по его URI .
2. Веб-сервер принимает запрос и устанавливает переменные окружения , через них приложению передаются данные и служебная информация.
3. Веб-сервер перенаправляет запросы через стандартный поток ввода (stdin) на вход вызываемой программы.
4. CGI-приложение выполняет все необходимые операции и формирует результаты в виде HTML.
5. Сформированный гипертекст возвращается веб-серверу через стандартный поток вывода (stdout). Сообщения об ошибках передаются через stderr.
6. Веб-сервер передает результаты запроса клиенту.

Области применения CGI

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

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

ОБРАТИТЕ ВНИМАНИЕ: CGI - это не язык программирования! Это простой протокол, позволяющий веб-серверу передавать данные через stdin и читать их из stdout. Поэтому, в качестве CGI-обработчика может ипользоваться любая серверная программа, способная работать со стандарными потоками ввода-вывода.

Hello, world!

Пример простого CGI-скрипта на языке Perl приведен в листинге 1. Если этот код сохранить в файле с именем hello (имя может быть любым, расширение - тоже), поместить файл в серверный каталог cgi-bin (точнее, в тот каталог веб-сервера, который предназначен для CGI-приложений и указан в настройках веб-сервера) и установить для этого файла права на исполнение (chmod uo+x hello), то он станет доступен по адресу вида http://servername/cgi-bin/hello.

Листинг 1. Пример CGI-скрипта (Perl)

#!/usr/bin/perl print "Content-type: text/html\n\n"; print <

Hello, world!

HTML exit;

В этом коде строка #!/usr/bin/perl указывает полный путь к интерпретатору Perl. Строка Content-type: text/html\n\n - http-заголовок, задающий тип содержимого (mime-type). Удвоенный символ разрыва строки (\n\n) - обязателен, он отделяет заголовки от тела сообщения.

Переменные окружения

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

Переменная окружения	Описание
CONTENT_TYPE	Тип данных, передаваемых на сервер. Используется, когда клиент отправляет данные, например, загружает файл.
CONTENT_LENGTH	Размер содержимого запроса. Эта переменная определена для POST-запросов.
HTTP_COOKIE	Возвращает набор «куков» в виде пар «ключ значение».
HTTP_USER_AGENT	Информация об агенте пользователя (браузере)
PATH_INFO	Путь к каталогу CGI
QUERY_STRING	Строка запроса (URL-encoded), передаваемая методом GET.
REMOTE_ADDR	IP-адрес клиента, выполняющего запрос.
REMOTE_HOST	Полное имя (FQDN) клиента. (Если доступно)
REQUEST_METHOD	Метод, которым выполняется запрос. Чаще всего GET или POST.
SCRIPT_FILENAME	Полный путь к запрашиваемому скрипту (в файловой системе сервера).
SCRIPT_NAME	Имя скрипта
SERVER_NAME	Имя сервера
SERVER_ADDR	IP-адрес сервера
SERVER_SOFTWARE	Информация о серверном ПО

В листинге 2 приведен код небольшой программы на Perl, выводящей список переменных окружения. Результат ее работы приведен на рис. 2.

Листинг 2. Переменные окружения

#!/usr/bin/perl print "Content-type: text/html\n\n"; print "\n\n

Environment

\n"; foreach (sort keys %ENV) { print "$_: $ENV{$_}
\n"; } print "\n"; exit;

Передача данных: метод GET

Метод GET используется для передачи urlencoded -данных через строку запроса. Адрес запрашиваемого ресурса (CGI-скрипта) и передаваемые ему данные отделяются знаком «?». Пример такого адреса:

http://example.com/cgi-bin/script.cgi?key1=value1&key2=value2

Метод GET используется по умолчанию для данных, введенных в адресную строку браузера. Такая же строка может быть сформирована при отправке данных из веб-формы (тег

), если метод передачи для формы не указан. Вся информация, отправляемая методом GET, передается в открытом виде, поэтому никогда не следует использовать его для отправки на сервер паролей или другой подобной информации. Метод GET имеет ограничение по размеру: строка запроса должна быть не длинее 1024 символов.

Информация, отправляемая методом GET передается в заголовке QUERY_STRING в виде строки, состоящей из пар вида ключ=значение , CGI-скрипт может получить ее через одноименную переменную окружения.

Листинг 3. Отправка данных из веб-формы методом GET

You name: name="user" >
Where are you from?: name="from" >

После ввода данных в форму из листинга 3 и нажатия кнопки "Submit" будет сформирована строка запроса вида:

http://example.com/cgi-bin/sayhello ?user =sometext &from =anothertext

где: sayhello - имя CGI-скрипта; user и from - имена параметров; sometext и anothertext - введенные пользователем значения соответствующих параметров.

В листинге 4 приведен пример скрипта, который может обработать данные формы из листинга 3.

Листинг 4. Отправка данных из веб-формы методом GET

#!/usr/bin/perl local ($buffer, @pairs, $pair, $name, $value, %FORM); # Анализируем окружение $ENV{"REQUEST_METHOD"} =~ tr/a-z/A-Z/; if ($ENV{"REQUEST_METHOD "} eq "GET ") { $buffer = $ENV{"QUERY_STRING "}; } # Разделяем строку запроса на пары вида ключ/значение @pairs = split(/&/, $buffer); foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); $value =~ tr/+/ /; $value =~ s/%(..)/pack("C", hex($1))/eg; $FORM{$name} = $value; # Сохраняем данные в массив } # Отправляем заголовок print "Content-type: text/html\n\n"; # Отправляем гипертекст print <

Hello, $FORM{user} from $FORM{from}!

HTML exit;

Передача данных: метод POST

В общем случае более подходящим для передачи информации CGI-скрипту является метод POST. Блок передаваемых данных формируется так же, как и для метода GET, но непосредственно передача осуществляется в теле запроса. Данные поступают на вход CGI-приложения через стандартный ввод (stdin).

Для отправки данных этим методом, он должен быть явно задан в описании формы (action="POST").

Для обработки входных данных CGI-скрипт должен прочитать stdin, а чтобы это правильно сделать, ему нужно узнать размер сообщения из переменной CONTENT_LENGTH. Для иллюстрации этого модифицируем блок анализа окружения в листинге 4, заменив его следующим кодом:

... # Анализируем окружение $ENV{"REQUEST_METHOD"} =~ tr/a-z/A-Z/; if ($ENV{"REQUEST_METHOD "} eq "POST "){ read(STDIN , $buffer, $ENV{"CONTENT_LENGTH "}); } ...

Дальнейшая обработка сохраненных в переменной $buffer параметров и их значений выполняется так же, как и в при использовании метода GET.

Преимущества CGI

Многие возможности CGI сейчас дублируются такими технологиями, как например DHTML , ActiveX или Java-апплетами. Основными преимуществами использования серверных скриптов является то, что вы можете быть уверены, что все клиенты (за редким исключением, как правило связанным с блокировкой доступа к определенным ресурсам на уровне файрвола) смогут работать с серверным приложением. Клиентские-же программы могут быть просто отключены в браузере, или вовсе не поддерживаться.

Недостатки CGI

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

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

Постоянный адрес этой страницы:

Страница 1 из 30

Сегодня такие вещи, как гостевая книга, поиск по серверу, форма для отправки сообщений - неотъемлемый атрибут практически любого серьезного сайта. Проблема внедрения этих и других прибамбасов, разумеется, всячески возбуждает воображение начинающего вебмастера, лишая его сна, аппетита и тяги к пиву. К сожалению, изучение HTML-исходников страниц конкурентов ничего, кроме ссылок на некий "cgi-bin", не дает, да еще в телеконференциях иногда встречается упоминание о каких-то cgi-скриптах. Эта статья и посвящена основам использования этих самых cgi-скриптов во славу и процветание вашего сайта.

Для начала, думаю, надо разобраться с понятиями. CGI-скрипт - это программа, которая выполняется на Web-сервере по запросу клиента (то есть посетителя Web-сайта). Программа эта принципиально ничем не отличается от обычных программ, которые установлены на вашем компьютере - будь то MS Word или игра Quake. CGI - это не язык программирования, на котором написан скрипт, а Common Gateway Interface - специальный интерфейс, с помощью которого и происходит запуск скрипта и взаимодействие с ним.

Краткое лирическое отступление насчет CGI

Итак что такое CGI - скрипты и вообще подобные вещи. Начнем с того что ваш браузер (когда вы набрали URL ) соединяется по протоколу HTTP с указаным сервером и просит у него нужный файл,примерно так:

GET /~paaa/cgi-bin/guestbbok.cgi HTTP/1.0 -Вот это самое главное в запросе

Ну и если запрошен простой файл например .html то если если такой файл есть, То сервер отошлет браузеру ответ:

HTTP/1.0 200 Okay
Content-Type: text/html

Далее после пустой строки(она нужна чтоб отделить заголовок от тела ) идет информация из самого URL "а ...
Вот в принципе и весь WWW ....ходишь от ссылки к ссылке....
А что если Нужно внести в этот унылый процесс что-нибудь по настоящему интерактивное, динамическое,прекрасное и великолепное....? Чтож есть ответ и на этот вопрос. Просто что если в запрашиваемом URL указать спецыальную программу (CGI ,программа Common Gateway Inteface - Общего Шлюзового Интерфейса ) и то что эта прога выдаст то и отправить браузеру....Сервер запускает .cgi программу и она например обработав данные формы заносит вас куда-нибудь в свою базу данных,а вам сообщит что вы большой молодец:)
Ну надеюсь я вас заинтриговал......?

Краткие сведения о том что надо знать чтоб писать CGI скрипты: Ну вопервых надо знать что такое интернет и как он работает (а вы знаете? ;))) ) Ну и чуть-чуть умения прграмировать(это самое главное)
Давайте вместе писанем какой нибудь простенький скриптик а потом я вам расскажу где сдесь собака порылась....
Ну сначала в своем домашнем каталоге создайте директорию cgi-bin :

cd public_html
mkdir cgi-bin
chmod 0777 cgi-bin

Последняя строчка будет очень важна.
Возьмите редактор и наберите: #!/usr/bin/perl
#first.cgi
print "Content-Type: text/html\n\n";
print "";
print "

Hello you!!!

";
print "";

Сохраните его в директории cgi-bin под именем first.cgi .Ну как сохранили?
А теперь сделайте его исполняемым(ведь это программа):

chmod +x first.cgi

Ну вот,подходим к торжественному моменту.... наберите в строке браузера http://www.uic.nnov.ru/~твой_логин/cgi-bin/first.cgi
и посмотрите чо будет. Будет одно из двух,либо скрипт заработает и вы увидите сгенерированую им страничку (поздравляю,в нашем полку прибыло!) либо Internal Server Error -тогда не расстраивайтесь,вы что-то сделали не так. Вам тогда пригодится пособие по ловле блох. Ну вопервых проверку синтаксиса можно осуществить следующим образом:

perl -с first.cgi

Perl вам сразу выдаст либо сообщения об ошибках(ну бывает,точку с запятой пропустили, скобочки или кавычки забыли закрыть...) это сразу по ходу дела поправимо.
Более грубая с логической точки зрения это пропустить вывод пустой строки, которая отделяет заголовок от тела:
print "Content-Type: text/html\n\n"; #Все Правильно
print "Content-Type: text/html\n"; #ОШИБКА!!!

Разберем скрипт:
Первая строка #!/usr/bin/perl Просто указывает где в системе расположен Perl. Вторая это просто коментарий -вы можете тыкать чо угодно после знака #
Затем идет print "Content-Type: text/html\n\n"; Это заголовок указывающий тип содержимого все что скрипт печатает в свой стандартный вывод STDOUT идет на обработку к серверу. Пустая строка отделяет заголовок от тела,которое в нашем случае представляет собой

Hello you!!!

Сервер обработает ответ скрипта и на базе него сформирует и пошлет браузеру ответ.(Сервер обычно не изменяет тела сообщения,он только дополняет заголовок нужными для протокола HTTP полями)

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

Новая страница 3

CGI

Скрипты CGI

Для того, чтобы Web-узлы были действительно интерактивными, она должны обмениваться информацией с пользователем, а не только позволять ему загружать документы. Используя программы Common Gateway Interface (называемые CGI-скриптами ), можно создавать Web-страницы, управляемые данными. Как вы узнаете, используя скрипты CGI, узел может получать запросы и отвечать пользователю.

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

Почему Web-узлы используют CGI

Для создания динамических файлов HTML нет необходимости в применении CGI-скриптов. Однако без таких скриптов всякий раз, когда понадобится новая интерактивная динамическая страница Web, придется модифицировать программу-сервер. Спустя какое-то время программа-сервер может стать исключительно большой. Для того чтобы исключить такую модификацию сервера, разработчики используют CGI. Используя CGI-скрипты, сервер может переложить задачу создания линамических Web-документов на прикладную программу, созданную для этих специфических потребностей. Вы будете создавать вашу прикладную программу, используя C/C++, Perl, JavaScript, VBScript, или какой-либо другой язык программирования.

Программа-сервер должна вызвать CGI-скрипт

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

Броузер, сервер и CGI

Как известно, для получения броузером HTML-документов, он сначала устанавливает контакт с сервером, затем запрашивает документ (обычно ваш броузер определяет GET- метод HTTP для получения информации от сервера). Далее, если документ существует, сервер отвечает броузеру, посылая ему HTML-документ, и затем закрывает соединение. Применение CGI-скриптов вносит изменения в этот процесс только на стороне сервера. Броузер не знает, что сервер вызывает CGI-скрипт, и он не заботится о том, каким именно способом поступают к нему данные от сервера. Как Web-программист, при написании CGI-скриптов вы заботитесь только о входах и выходах сервера. Броузер будет устанавливать контакт с программой сервера, которая, в свою очередь, исполняет CGI-скрипт. Ваш скрипт, в свою очередь, выполняет необходимую обработку данных, чтобы сформатировать требуемый выход. Обычно ваш сервер передает выходные данные из скрипта в форме HTML-броузеру. Чтобы выполнить это, верверная программа добавляет необходимую заголовочную информацию к выходным данным, сформированным скриптом, и посылает эту заголовочную информацию вместе с данными обратно броузеру. Затем сервер закрывает соединение и ждет новых запросов.

Как вы, возможно, знаете, серверы, которые работают под 32-битными операционными системами, такими как Windows 95/98 или Windows NT , могут обрабатывать запросы от многих пользователей одновременно. Отсюда следуте, что несколько пользователей могут одновременно использовать скрипт. Поэтому каждый из них, в зависимости от запроса, будет видетьь свою картину ответа сервера.

Взаимосвязь сервера и CGI-скрипта

Когда серверная программа вызывает скрипт, сервер должен выполнить несколько основных операций: вызвать скрипт и обеспечить его необходимыми данными, посылаемыми от броузера вашему скрипту, снабдить скрипт значениями переменных окружения , доступных скрипту, и обработать выход скрипта, в том числе обеспечить включение дополнительной заголовочной информации, необходимой для броузера, чтобы успешно интерпретировать данные скрипта.

Как вы уже знаете, HTTP является протоколом, с помощью которого клиенты и серверы Web обеспечиваются информацией. Заголовочная HTTP информация помогает программам эффективно выполнять обмен данными. Поэтому необходимо уделить особое внимание заголовочной информации, которой сервер снабжает броузер. Например, когда программа-сервер готова послать данные броузеру, она посылает заголовки, описывающие статус данных, тип данных и т.д. В свою очередь броузер использует заголовок (Content-type ) для подготовки к выводу данных на экран. Сервер отвечает за то, чтобы обеспечить этой метаинформацией броузер каждый раз, когда он посылает ему данные.

CGI т базы данных

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

Где находятся скрипты

Стандарты CGI не предписывают, куда должны помещаться скрипты, то есть не определяют заранее диск и каталог. Обычно Web-сервер ожидает найти скрипты в каталоге /CGI-BIN, который расположен нажи каталога самой программы сервера. Если вы помещаете свои скрипты на чей-то сервер, необходимо определить каталог для своих файлов, содержащих скрипты.

Расширение имен файлов CGI-скриптов

Серверы HTTP для Windows-систем обычно для CGI-файлов используют расшерение EXE или PL. Например, если вы создаете CGI-программу (скрипт), используя язык программирования С, то расширение ваших файлов-скриптов будет, вероятно, ЕХЕ. Аналогично, если вы создаете скрипт с помощью языка Perl, расширение ваших файлов будет PL.

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

Основы взаимодействия между Web-сервером и CGI-скриптом

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

Когда пользователь Web устанавливает связь, в результате которой сервер вызывает скрипты, серверу требуется большое число переменных окружения, используемых скриптом для получения информации. Эти переменные окружения содержат информацию о броузере, который посылает запрос, сервере, который его обрабатывает, данных, передаваемых вашему скрипту. Переменные окружения CGI чувствительны к регистру, и каждая из переменных определена в спецификации CGI.

Переменные окружения

Переменная AUTH_TYPE

Скрипты CGI используют переменную окружения AUTH_TYPE для идентификации пользователя, который пытается получить доступ к скрипту. Если сервер сконфигурирован так, чтобы поддерживать идентификацию пользователя, то пользователь, пытающийся получить доступ к скрипту, должен назвать свое имя и пароль. Например, следующее значение переменной означет, что от пользователя требуется основной уровень идентификации:

AUTH_TYPE = Basic

Переменная CONTENT_LENGTH

Скрипты используют переменную окружения CONTENT_LENGTH для того, чтобы определить точное число байт, содержащихся в просоединенных данных. Например, если запрос содержит документ длиной в 1,024 байта, то переменной окружения присваивается следующее значение:

CONTENT_LENGTH = 1024

Переменная CONTENT_TYPE

Скрипты используют эту переменную окружения для запросов, которые содержат присоединенную информацию. К такому типу запросов отоносится HTTP-операция POST. Содержащаяся в переменной информация указывает на тип присоединенных данных (MIME-тип.подтип). Например, если запрос содержит присоединенный документ HTML , то переменная окружения будет принимать следующие значения:

CONTENT_TYPE = text/html

Переменная GATEWAY_INTERFACE

Скрипты используют эту переменную для того, чтобы определить версию, номер выпуска спецификации CGI, которой удовлетворяет Web-сервер. Формат номера выпуска спецификации следующий: CGI/номер выпуска. Например, для CGI выпуска 1.1 переменная окружения будет иметь следующий вид:

GATEWAY_INTERFACE = CGI/1.1

Переменная PATH_INFO

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

Путь записывается в относительной форме, где за базу берется корневой каталог сервера. Иными словами, корневой каталог сервера является базисом для относительного пути, который и присваивается переменной PATH_INFO . Например, если задан путь c:/cgi-bin/example1.exe/sports.html, то переменная окружения будет иметь следующий вид:

PATH_INFO = /sports.html

Переменная PATH_TRANSLATED

Скрипты используют эту переменную для получения окончательной, пригодной для непосредственного использования информации относительно пути. Сервер переводит информацию переменной путем выполнения необходимых преобразований пути. Например, если переменная PATH_TRANSLATED имеет значение /sports.html, а корневым дирикторием сервера служит c:\, то переменная окружения будет иметь следующее значение:

PATH_TRANSLATED = c:\sports.html

Переменная QUERY_STIRNG

Скрипты используют эту переменную для того, чтобы получить информацию в текстовой форме (состоящую из аргументов), которая следует справа от знака вопроса после URL, переданного от пользователя скрипту для обработки. Эта текстовая сторока содежит вход для скрипта. Далее сервер заменяет в данном тексте каждый пробел на знак " + ", а все непечатные символы знаком " %dd", где d является базой десятичной системы счисления.

Скрипт должен содержать код для расшифровки этой текстовой строки. Сервер, передавая эту информацию скрипту, не должен заниматься декодированием информации запроса каким-либо образом. Сервер должен также установить переменную QUERY_STRING в случае, если пользователь обеспечивает какую-то информацию запроса. Например, для URL http://www.jamsa.com/cgi-bin/grandma.exe?name=margaret+alarcon переменная окружения имеет значением следующую величину:

QUERY_STRING = name=margaret+alarcon

Переменная REMOTE_ADDR

Скрипты используют эту переменную для получения IP-адресса удаленного узла (броузера), который делает запрос. Например, значение переменной окружения может быть следующим:

REMOTE_ADDR = 204.212.52.209

Переменная REMOTE_HOST

Скрипты используют эту переменную для того, чтобы получить имя узла, с которого делается запрос. Если сервер не знает имя узла, делающего запрос, то сервер должен присвоить значение переменной окружения REMOTE_ADDR и не присваивать значения переменной REMOTE_HOST . Напрмиер, для узла jamsa.com переменная окружения будет содержать следующее значение:

REMOTE_HOST = jamsa.com

Переменная REMOTE_IDENT

Используется для того, чтобы получиь имя удаленного пользователя, делающего запрос к серверу. Программа Web-сервера представляет собой программное обеспечение. вызывающее ваш скрипт. Если HTTP Web-сервер поддерживает протокол RFS 931 (Authentication Server Protocol), то сервер установит эту переменную равной значению имени пользователя, которое имеется у сервера. Скрипты могут использовать эту переменную только для регестрации пользователя. Напрмер, если имя удаленного пользователя pschmauder и он назодится на удаленном узле jamsa.com , то переменная примет следующее значение:

REMOTE_IDENT = pschmauder.www.jamsa.com

Переменная REMOTE_USER

Используется для того, чтобы получить имя удаленного пользователя без имени узла, с которого он производит запрос. Если сервер поддерживает идентификацию пользователя и скрипт является защищенным, то сервер установит имя пользователя и присвоит его этой переменной. Например, предположим, что именем удаленного пользователя является pschmauder . Тогда переменная будет выглядеть следующим образом:

REMOTE_USER = pschmauder

Переменная REQUEST_METHOD

Используется для того, чтобы определить тип HTTP-запроса, который послан броузером серверу и служит для вызова скриптов. Эта переменная может принимать значения GET, HEAD или POST. Например, если броузер посылает GET- метод, то переменная окружения содержит следующее:

REQUEST_METHOD = GET

Переменная SCRIPT_NAME

Используется для того, чтобы определить виртуальный путь к скрипту, который будет запущен сервером. Например, если имеется URL http://www.jamsa.com/cgi-bin/someprog.exe , то переменная окружения примет следующее значение:

SCRIPT_NAME = cgi-bin/example1.exe

Переменная SERVER_NAME

Использутся для того, чтобы определитьимя домена ли IP-адрес комрьютера, на котором раположен Web-сервер. Например, когда сервер возвращает IP-адрес, переменная окружения будет иметь вид, подобный следующему:

SERVER_NAME = 204.212.52.209

Переменная SERVER_PORT

Используется для того, чтобы определить номер порта, который пользователь (броузер) использует для связи с Web-сервером. Если используется HTTP-порт по умолчанию, то эта величина равна 80. Если используется какой-то другой порт, например, http://www.jamsa.com:3000 , то переменная принимает следующее значение:

SERVER_PORT = 3000

Переменная SERVER_PROTOCOL

Используется для того, чтобы определить имя и номер выпуска протокола, используемогоклиентом (броузером) для того, чтобы послать запрос к Web-серверу. Анализируя содержание переменной, скрипт может идентифицировать имя и номер выпуска протокола, который он должен использовать при передаче данных серверу. Формат имени протокола и номера выпуска следующий: протокол/номер выпуска. Например, для HTTP 1.1 переменная окружения будет иметь следующий вид:

SERVER_PROTOCOL = HTTP/1.1

Переменная SERVER_SOFTWARE

Как вы знаете, Web-сервер исполняет скрипты CGI. Поскольку скрипт может испольняться по-разному для различных серверных программ, скрипты используют эту переменную для того, чтобы определить имя программы Web-сервера и ее номер версии. Формат имени Web-сервера и номер версии должен передаваться CGI следующим образом: имя/версия. Например, для FOLK WEB - сервера версии 1.01 переменная окружения будет иметь седующий вид:

SERVER_SOFTWARE = FolkWeb/1.01 (Windows-32bit)

Дополнительные переменные окружения

В дополнение к переменным окружения. обсуждавшимся ранее, сервер также помещает данные из заголовка запроса, полученного от клиента, в переменные окружения. Сервер присваивает значения переменным, чьи имена начинаются с префикса HTTP_, после которого идет имя заголовка. Сервер заменяет все символы переноса (-) в заголовке на (_). Сервер может также исключать любые заголовки, которые он уже обработал, используя переменные окружения, такие как AUTH_TYPE, CONTENT_TYPE и CONTENT_LENGTH.

Переменная HTTP_ACCEPT

Используется для того, чтобы определить, какие MIME-типы может принимать броузер. Они определены в HTTP-заголовках, которые броузер послал серверу. Как известно, MIME-тип задается в виде тип/расширение. Если имеется насколько MIME-типов, то они разделяются запятыми. Например, переменная окружения может принимать следующее значение:

HTTP_ACCEPT = audio/aif, text/html, text/plain

Переменная HTTP_USER_AGENT

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

HTTP_USER_AGENT = Mozilla/2.01 Gold(Win95PE)

Опции командной строки CGI

Обычно CGI-скрипты используют командную строку в качестве входа для того, чтобы выполнить запрос ISINDEX, позволяющий добавить интерактивный поиск по ключевому слову к вашему HTML-документы. Однако не все серверные программы поддерживают ISINDEX- запрос. Броузер посылает запрос в виду командкной строки серверу. Программа сервера может идентифицировать входную командную строку, устанавливая, использовал ли броузер GET- метод HTTP и содержит ли строка URL символы uuencoded = .

Если броузер использует GET- метод HTTP и строка URL-поиска не содержит символы uuencoded =, то запрос осуществляется в форме командной строки. Перед тем как сервер вызовет соответствующий скрипт, серверная программа должна расщепить командную строку, используя знак (+), для отделения параметров. Затем сервер выполняет дополнительное декодирование (если необходимо) каждого параметра, переданного в URL-строке поиска, и хранит каждый параметр-строку в массиве, названную argv.

Дополнительное декодирование, выполняемое сервером, состоит в разделении отдельных строк, используя амперсанда (&) в качестве разделителя. Далее сервер расщепляет каждую из этих строк снова, используя знак (=) для того, чтобы отделить имя переменной, которое ставиться слева от знака (=), от значения переменной, которое стоит справа от (=). Сервер хранит число элементов, содержащихся в массиве argv , в переменной целого типа argс .

Если сервер нашел знак равенства внутри строки QUERY_STRING переменной окружения, то он не будет посылать командную строку в качестве входа в скрипт. Также если по какой-то причине программа сервера не может послать массив argv скрипту, она обеспечит недекодированную информацию запроса в переменной окружения QUERY_STRING.

Стандартный ввод (STDIN )

Когда броузер запрашивает сервер (например, используя HTTP-метод POST ), информация, которую получает скрипт, приходит со стандартного дескриптора ввода stdin. Серверная программа посылает скрипту переменную окружения CONTENT_LENGTH. Эта переменная содержит число байт, которое сервер посылает скрипту через этот дескриптор. Скрипт может использовать значение переменной CONTENT_LENGTH для того, чтобы определить, сколько данных должно поступить со стандартного ввода. Сервер также снабжает скрипт переменной окружения CONTENT_TYPE , которая помогает скрипту определить, как обрабатывать получаемые данные. В конце этого потока данных сервер может послать (а может и не посылать) маркер конца файла. Однако именно скрипт обязан определить, какой объем данных читать, и использует он для этого переменную окружения CONTENT_LENGTH.

Например, если форму использует HTTP-метод POST (

) и посланные серверу данные закодированы следующим образом: name=alberta&husband=art , то сервер присвоит переменным CONTENT_LENGHT и CONTENT_TYPE следующие значения:

CONTENT_LENGHT = 24 CONTENT_TYPE = APPLICATION/x-www-form-urlencoded

Стандартный вывод (STDOUT )

После того как CGI-скрипт закончит обрабатывать полученные от сервера данные, он должен посылать свой ответ серверу. Для того, чтобы послать свои данные серверу, он должен посылать их файловому дескриптору стандартного выводы STDOUT . В общем случае данные, которые скрипт посылает назад серверу, представляет собой HTTP-ответ, включающий заголовок, после которого идет пустая строка и за ней остальная часть ответа. Обычно выходом скрипта служат документы HTML, созданные скриптом.

Прямой ответ скрипта броузеру

Обычно скрипт выдает ответ, который сервер интерпретирует и посылает назад броузеру. Преимуществом посылки выходных данных от скрипта серверу служит то, что скрипт в таком случае не обязан посылать полный заголовок HTTP на каждый запрос. Однако некоторые скрипты разгружают сервер и шлют свои выходные данные прямо броузеру. Для того, чтобы можно было отличить такие скрипты, которые шлют данные непосредственно броузеру, от скриптов, которые направляют их серверу, протокол CGI требует, чтобы имена скриптов, осуществляющих прямую посылку броузеру, начинались с букв nph- (которые говорят серверу Not to Parse the Header - не инициализировать заголовок). Если имя скрипта начинается так, то сервер не будет вставлять заголовок в данные скрипта. В таком случае ответственность возлагается на сам скрипт.

Заголовки CGI

Как вы узнали ранее, выходные данные скрипта начинаются с заголовка. Этот заголовок состоит из строки текста в том же формате, что и заголовок HTTP, оканчиваясь пустой строкой (строкой, которая содержит только CRLF). Если выходные данные скрипта содержат заголовки, не являющиеся директивами серверу , то сервер посылает эти заголовки броузеру в ответе на его запрос. Текущая спецификация CGI пределяет три директивы:

• CONTENT-TYPE
• LOCATION
• STATUS

Поле Content-type в заголовке CGI определяет тип/расширение MIME-данных, которые скрипт посылает назад броузеру. Обычно скрипты выдают на выходе документ HTML. В этом случае заголовок CGI Content-type содержит следующее:

Content-type: text/html

Поле Location заголовка указывает на документ. Скрипты обычно используют поле Location для указания местонахождения документа. В случае, если документ находится не на сервере и содержимым поля является URL, сервер перенаправляет броузерна соответствующий узел. Если же документ находится на сервере и поле представляет собой виртуальный путь, сервер выдает этот документ броузеру. Например, для того чтобы указать на документ на удаленном сервере, значение поля в заголовке может иметь вид:

Location: htpp://www.cetis.ru

Поле Status заголовка содержит значение статуса HTTP, которое сервер направляет от скрипта броузеру. Сервер, который вызывает скрипт, использует различные коды статуса HTTP. Вы можете захотеть направлять код статуса прямо броузеру, особенно в случае возникновения ошибок.

В следующем примере проиллюстрирован типичный вывод скрипта, который он должен генерировать при посылке данных серверу. После того как данные достигнут серверной программы, сервер направит данные броузеру:

Content-type: text/html This is body generated by your CGI script.

Обратите внимание на пустую строку меду первыми строками. Эта пустая строка абсолютно необходима. Следующий фрагмент кода на языке С создает записанный выше документ с использованием функции printf:

// More code above: printf("Content-type: text/html\n"); printf("\n"); // Make sure to include this blank line printf("\n"); printf("\n"); printf("\n"); printf("\n"); printf("\n"); printf("This is the body generated by your CGI script.\n"); printf("\n"); printf("\n"); // More code bellow...

• Tutorial

Добрый день.
В этой статье я бы хотел рассказать про протокол FastCGI и способы работы с ним. Не смотря на то, что сам протокол и его реализация появились ещё в 1996 году, подробных руководств по этому протоколу просто нет - разработчики так и не написали справки к собственной библиотеке. Зато года два назад, когда я только начал пользоваться этим протоколом, часто встречались фразы типа «я не совсем понимаю, как пользоваться этой библиотекой». Именно этот недостаток я и хочу исправить - написать подробное руководство по использованию данного протокола в многопоточной программе и рекомендации по выбору различных параметров, которым могли бы воспользоваться все желающие.

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

Итак, в этой статье мы рассмотрим:
- Что такое FastCGI и чем отличается от протокола CGI
- Зачем мне нужен FastCGI, когда уже есть много языков для разработки под веб
- Какие реализации протокола FastCGI существуют
- Что такое сокеты
- Описание функций библиотеки FastCGI
- Простой пример многопоточной FastCGI-программы
- Простой пример конфигурации Nginx
К сожалению, очень сложно написать статью одинаково понятной новичкам и интересной опытным старожилам, поэтому я буду стараться осветить все моменты как можно подробнее, а Вы можете просто пропустить неинтересные Вам разделы.

Что такое FastCGI?

Про FastCGI можно прочитать в Википедии . Если в двух словах, это CGI-программа, запущенная в цикле. Если обычная CGI-программа заново запускается для каждого нового запроса, то в FastCGI-программе используется очередь запросов, которые обрабатываются последовательно. А теперь представьте: на Ваш 4-8-ядерный сервер поступило 300-500 одновременных запросов. Обычная CGI-программа будет запущена на выполнение эти самые 300-500 раз. Очевидно, такого количества процессов слишком много - Ваш сервер физически не сможет отработать их все сразу. Значит, у Вас получится очередь процессов, ожидающих свой квант процессорного времени. Обычно планировщик будет распределять процессорное равномерно (так так в данном случае приоритеты всех процессов одинаковые), а значит у Вас будет 300-500 «почти готовых» ответов на запросы. Звучит как-то не очень оптимистично, не правда ли? В FastCGI-программе все эти проблемы решаются простой очередью запросов (то есть применяется мультиплексирование запросов).

Зачем мне FastCGI, когда уже есть PHP, Ruby, Python, Perl и т.п.?

Пожалуй, главная причина - компилируемая программа будет работать быстрее интерпретируемой. Для PHP, например, существует целая линейка акселераторов, среди которых - APC, eAccelerator, XCache, которые уменьшают время интерпретации кода. Но для C/C++ всё это просто не нужно.
Второе, о чём Вы должны помнить - динамическая типизация и сборщик мусора занимают много ресурсов. Иногда - очень много. Например, массивы целых чисел в PHP занимают примерно в 18 раз больше памяти (до 35 раз в зависимости от различных параметров компиляции PHP), чем в C/C++ для того же объема данных, поэтому задумайтесь о накладных расходах для сравнительно больших структур данных.
Третье - FastCGI-программа может хранить общие для разных запросов данные. Например, если PHP каждый раз начинает обработку запроса с «чистого листа», то FastCGI-программа может сделать ряд подготовительных действий ещё до поступления первого запроса, например выделить память, загрузить часто используемые данные и т.п. - очевидно, всё это может повысить общую производительность системы.
Четвёртое - масштабируемость. Если mod_php предполагает, что веб-сервер Apache и PHP находятся на одной и той же машине, то FastCGI-приложение может использовать TCP-сокеты. Другими словами, у Вас может быть целый кластер из нескольких машин, связь с которыми осуществляется по сети. При этом FastCGI также поддерживает Unix domain sockets, что позволяет при необходимости эффективно запускать FastCGI-приложение и веб-сервер на одной и той же машине.
Пятое - безопасность. Вы не поверите, но с настройками по умолчанию Apache позволяет выполнять всё на свете. Например, если злоумышленник загрузит на сайт вредоносный скрипт exploit.php.jpg под видом «невинной картинки» и потом откроет её в браузере, Apache «честно» выполнит вредоносный php-код. Пожалуй, единственное достаточно надежное решение - удалять или изменять все потенциально опасные расширения из имен загружаемых файлов, в данном случае - php, php4, php5, phtml и т.п. Такой приём используется, например, в Drupal - ко всем «дополнительным» расширениям добавляется символ подчеркивания и получается exploit.php_.jpg. Правда следует отметить, что системный администратор может добавить любое дополнительное расширение файла в качестве обработчика php, так что какое-нибудь.html может вдруг превратиться в ужасную дыру в безопасности только из-за того, что.php выглядело некрасиво, было плохо для SEO или не нравилось заказчику. Итак, что же нам даёт в плане безопасности FastCGI? Во первых, если использовать вместо Apache веб-сервер Nginx, то он будет просто отдавать статические файлы. Точка. Другими словами, файл exploit.php.jpg будет отдан «как есть», без какой-либо обработки на стороне сервера, так что запустить вредоносный скрипт просто не получится. Во вторых, FastCGI-программа и веб-сервер могут работать из под разных пользователей, а значит и права на файлы и папки у них будут разные. Например, веб-сервер может только читать загруженные файлы - для отдачи статических данных этого достаточно, а FastCGI-программа может только читать и изменять содержимое папки с загружаемыми файлами - этого достаточно для загрузки новых и удаления старых файлов, но доступа непосредственно к самим загруженным файлам иметь не будет, а значит выполнить вредоносный код тоже не сможет. В третьих, FastCGI-программа может работать в chroot"е, отличном от chroot"а веб-сервера. Сам по себе chroot (смена корневой директории) позволяет сильно ограничить права программы, то есть повысить общую безопасность системы, потому что программа просто не сможет получить доступ к файлам за пределами указанного каталога.

Какой веб-сервер с поддержкой FastCGI лучше выбрать?

Если коротко - я пользуюсь Nginx . Вообще, серверов с поддержкой FastCGI довольно много, в том числе коммерческих, так что позвольте рассмотреть несколько альтернатив.
Apache - пожалуй, это первое, что приходит в голову, правда он потребляет гораздо больше ресурсов, чем Nginx. Например, на 10 000 неактивных HTTP keep-alive соединений Nginx расходует около 2,5M памяти, что вполне реально даже для сравнительно слабой машины, а Apache вынужден создавать новый поток для каждого нового соединения, так что 10 000 потоков - просто фантастика.
Lighttpd - главный недостаток этого веб-сервера в том, что он обрабатывает все запросы в одном потоке. Это значит, что могут быть проблемы с маштабируемостью - Вы просто не сможете задействовать все 4-8 ядер современных процессоров. И второе - если по какой-то причине подвиснет поток веб-сервера (например из-за длительного ожидания ответа от жесткого диска), у вас «зависнет» весь сервер. Другими словами, все остальные клиенты перестанут получать ответы из-за одного медленного запроса.
Еще один кандидат - Cherokee . По заявлениям разработчиков, в ряде случаев работает быстрее Nginx и Lighttpd.

Какие есть реализации протокола FastCGI?

На данный момент есть две реализации протокола FastCGI - библиотека libfcgi.lib от создателей протокола FastCGI, и Fastcgi++ - библиотека классов на С++. Libfcgi разрабатывалась с 1996 года и, по заявлениям Open Market, является очень стабильной, к тому же более распространена, поэтому пользоваться в этой статье будем ей. Хочется отметить, что библиотека написана на C, встроенную «обертку» C++ нельзя назвать высокоуровневой, поэтому будем использовать C-интерфейс.
Думаю, на установке самой библиотеки останавливаться смысла нет - в ней есть makefile, так что проблем быть не должно. Кроме того, в популярных дистрибутивах эта библиотека доступна из пакетов.

Что такое сокеты?

Общее понятие о сокетах можно получить в Википедии . Если в двух словах, сокеты - это способ межпроцессного взаимодействия.
Как мы помним, во всех современных операционных системах каждый процесс использует собственное адресное пространство. За непосредственный доступ к оперативной памяти отвечает ядро операционной системы, и если программа обратиться по несуществующему (в контексте данной программы) адресу памяти, ядро вернет segmentation fault (ошибка сегментирования) и закроет программу. Это замечательно - теперь ошибки в одной программе просто не могут повредить другим - они находятся как бы в других измерениях. Но раз у программ разное адресное пространство, от общих данных или обмена данными тоже быть не может. А если очень нужно передать данные из одной программы в другую, как тогда? Собственно, для решения этой проблемы и разрабатывались сокеты - два или более процесса (читайте: программы) подключаются к одному и тому же сокету и начинают обмен данными. Получается этакое «окно» в другой мир - через него можно получать и отправлять данные в другие потоки.
В зависимости от типа использования соединения сокеты бывают разные. Например, есть TCP-сокеты - они используют обычную сеть для обмена данными, то есть программы могут работать на разных компьютерах. Второй наиболее распространенный вариант - доменные сокеты Unix (Unix domain socket) - пригодны для обмена данными только в рамках одной машины и выглядят как обычный путь в файловой системе, но реально жесткий диск не используется - весь обмен данными происходит в оперативной памяти. Из-за того, что не нужно использовать сетевой стек, работают несколько быстрее (примерно на 10%), чем TCP-сокеты. Для ОС Windows данный вариант сокетов называется named pipe (именованный канал).
Примеры использования сокетов для ОС GNU/Linux можно найти в этой статье . Если Вы еще не работали с сокетами, я бы рекомендовал с ней ознакомиться - это не является обязательным, но улучшит понимание изложенных здесь вещей.

Как пользоваться библиотекой Libfcgi?

Итак, мы хотим создать многопоточное FastCGI-приложение, поэтому разрешите описать ряд наиболее важных функций.
Прежде всего, библиотеку нужно инициализировать:
int FCGX_Init(void);
Внимание! Эту функцию нужно вызывать перед любыми другими функциями этой библиотеки и только один раз (всего один раз, для любого количества потоков).

Далее нам нужно открыть слушающий сокет:
int FCGX_OpenSocket(const char *path, int backlog);
Переменная path содержит строку подключения к сокету. Поддерживаются как доменные сокеты Unix, так и TCP-сокеты, всю необходимую работу по подготовке параметров и вызова функции библиотека сделает сама.
Примеры строк подключения для доменных сокетов Unix:
"/tmp/fastcgi/mysocket" "/tmp/fcgi_example.bare.sock"
Думаю, тут всё понятно: нужно просто передать уникальный путь в виде строки, при этом все взаимодействующие с сокетом процессы должны иметь к нему доступ. Еще раз повторюсь: этот способ работает только в рамках одного компьютера, но несколько быстрее, чем TCP-сокеты.
Примеры строк подключения для TCP-сокетов:
":5000" ":9000"
В этом случае открывается TCP-сокет на указанном порту (в данном случае - 5000 или 9000 соответственно), при этом запросы будут приниматься с любого IP-адреса. Внимание! Данный способ потенциально небезопасен - если Ваш сервер подключен к сети Internet, то Ваша FastCGI-программа будет принимать запросы от любого другого компьютера. Значит, любой злоумышленник сможет отправить Вашей FastCGI-программе «пакет смерти». Разумеется, ничего хорошего в этом нет - в лучшем случае Ваша программа может просто «упасть» и получится отказ в обслуживании (DoS-атака, если хотите), в худшем - удаленное выполнение кода (это если совсем уж не повезёт), поэтому всегда ограничивайте доступ к таким портам при помощи файервола (межсетевого экрана), при этом доступ нужно предоставлять только тем IP-адресам, которые реально используются при штатной работе FastCGI-программы (принцип «запрещено все, что явно не разрешено»).
Следующий пример строк подключения:
"*:5000" "*:9000"
Способ полностью аналогичен предыдущему: открывается TCP-сокет с приёмом соединений от любого IP-адреса, поэтому в этом случае так же необходимо со всей тщательностью настраивать файервол. Единственный плюс от такой строки подключения сугубо административный - любой читающий конфигурационные файлы программист или системный администратор поймёт, что Ваша программа принимает соединения с любого IP-адреса, поэтому при прочих равных условиях лучше предпочесть данных вариант предыдущему.
Более безопасный вариант - явно указать IP-адрес в строке подключения:
"5.5.5.5:5000" "127.0.0.1:9000"
В этом случае запросы будут приниматься только от указанного IP-адреса (в данном случае - 5.5.5.5 или 127.0.0.1 соответственно), для всех остальных IP-адресов данный порт (в данном случае - 5000 или 9000 соответственно) будет закрыт. Это повышает общую безопасность системы, поэтому по возможности всегда используйте этот формат строки подключения к TCP-сокетам - а вдруг системный администратор «просто забудет» настроить файервол? Прошу обратить внимание на второй пример - там указан адрес той же машины (localhost). Это позволяет создать TCP-сокет на одной и той же машине, если по каким-то причинам Вы не можете использовать доменные сокеты Unix (например, потому что chroot веб-сервера и chroot FastCGI-программы находятся в разных папках и не имеют общих файловых путей). К сожалению, Вы не можете указать два или более разных IP-адреса, поэтому если Вам действительно нужно принимать запросы от нескольких веб-серверов, расположенных на разных компьютерах, то придётся или полностью открыть порт (см. предыдущий способ) и положиться на настройки Вашего файервола, или использовать несколько сокетов на разных портах. Так же библиотека libfcgi не поддерживает IPv6-адреса - в далёком 1996 году этот стандарт только-только появился на свет, так что придётся ограничить свои аппетиты обычными IPv4-адресами. Правда, если Вам действительно необходима поддержка IPv6, её сравнительно просто добавить, пропатчив функцию FCGX_OpenSocket - лицензия библиотеки это позволяет.
Внимание! Использование функции указания IP-адреса при создании сокета не является достаточной защитой - возможны атаки IP-спуфинга (подмены IP-адреса отправителя пакета), поэтому настройка файервола всё равно обязательна. Обычно в качестве защиты от IP-спуфинга файервол проверяет соответствие между IP-адресом пакета и MAC-адресом сетевой карты для всех хостов нашей локальной сети (точнее - для широковещательного домена с нашим хостом), и отбрасывает все поступающие из Интернета пакеты, обратный адрес которых находится в зоне частных IP-адресов или локального хоста (маски 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, 127.0.0.0/8 и::1/128). Тем не менее, всё же лучше использовать данную возможность библиотеки - в случае неверно настроенного файервола отправить «пакет смерти» с подделанного IP-адреса гораздо сложнее, чем с любого, так как TCP-протокол имеет встроенную защиту от IP-спуфинга.
Последний вид строки подключения - использовать доменное имя хоста:
"example.com:5000" "localhost:9000"
В этом случае IP-адрес будет получен автоматически на основе доменного имени указанного Вами хоста. Ограничения всё те же - хосту должен соответствовать один IPv4-адрес, иначе возникнет ошибка. Правда, учитывая что сокет создается один раз в самом начале работы с FastCGI, вряд ли этот способ будет очень полезен - динамически менять IP-адрес всё равно не получится (точнее, после каждой смены IP-адреса придётся перезапускать Вашу FastCGI-программу). С другой стороны, возможно это будет полезно для сравнительно большой сети - запомнить доменное имя всё же легче, чем IP-адрес.

Второй параметр функции backlog определяет длину очереди запросов сокета. Специальное значение 0 (нуль) означает длину очереди по умолчанию для данной операционной системы.
Каждый раз, когда приходит запрос от веб-сервера, новое соединение ставится в эту очередь в ожидании обработки нашей FastCGI-программой. Если очередь полностью заполнится, все последующие запросы на соединение будут заканчиваться неудачей - веб-сервер получит ответ Connection refused (в подключении отказано). В принципе, ничего плохого в этом нет - у веб-сервера Nginx есть своя очередь запросов, и если свободных ресурсов нет, то новые запросы будут ожидать своей очереди на обработку уже в очереди веб-сервера (по крайней мере до тех пор, пока не истечёт время ожидания). Кроме того, если у Вас несколько серверов с работающей FastCGI-программой, Nginx может передать такой запрос на менее загруженный сервер.
Итак, давайте попробуем разобраться, какая длина очереди будет оптимальной. Вообще, этот параметр лучше настраивать индивидуально исходя из данных нагрузочного тестирования, но мы попробуем оценить наиболее подходящий диапазон для этой величины. Первое, что нужно знать - максимальная длина очереди ограничена (определяется настройками ядра операционной системы, обычно - не более 1024 подключений). Второе - очередь потребляет ресурсы, копеечные, но всё же ресурсы, поэтому необоснованно длинной её делать не стоит. Далее, допустим у нашей FastCGI-программы есть 8 рабочих потоков (вполне реально для современных 4-8-ядерных процессоров), и каждому потоку нужно собственное подключение - задачи обрабатываются параллельно. Значит, в идеале, у нас уже должно быть 8 запросов от веб-сервера, чтобы сразу же, без ненужных задержек, обеспечить работой все потоки. Другими словами, минимальный размер очереди запросов - это количество рабочих потоков FastCGI-программы. Можно попробовать увеличить эту величину на 50%-100%, чтобы обеспечить некоторый запас по загрузке, так как время передачи данных по сети конечно.
Теперь давайте определимся с верхней границей этой величины. Тут нужно знать, сколько запросов мы реально можем обработать и ограничить очередь запросов этой величиной. Представьте, что Вы сделали эту очередь слишком большой - настолько, что Вашим клиентам просто надоедает ждать своей очереди и они просто уходят с Вашего сайта так и не дождавшись ответа. Очевидно, ничего хорошего в этом нет - веб-сервер должен был отправить запрос на открытие соединения, что само по себе дорого, а потом ещё и закрыть это соединение только лишь по тому, что FastCGI-программе не хватило времени на обработку этого запроса. Одним словом, мы только тратим процессорное время впустую, а ведь его нам как раз и не хватает! Но это еще не самое страшное - хуже, когда клиент отказался от получения информации с Вашего сайта уже поле начала обработки запроса. Получается, что мы должны будем полностью обработать в сущности уже никому не нужный запрос, что, согласитесь, только ухудшит ситуацию. Теоретически может возникнуть ситуация, когда большая часть клиентов так и не дождется ответа при 100% загрузке Вашего процессора. Нехорошо.
Итак, допустим один запрос мы можем обработать за 300 миллисекунд (то есть 0,3 секунды). Далее нам известно, что в среднем 50% посетителей покидают ресурс, если веб-страница грузится более 30 секунд. Очевидно, что 50% недовольных - это слишком много, поэтому ограничим максимальное время загрузки страницы в 5 секунд. При этом имеется ввиду уже полностью готовая веб-страница - после применения каскадных таблиц стилей и выполнения JavaScript"ов - этот этап на среднестатистическом сайте может занимать 70% от общего времени загрузки веб-страницы. Итак, на загрузку данных по сети осталось не больше 5*0,3 = 1,5 секунд. Дальше следует вспомнить, что html-код, таблицы стилей, скрипты и графика передаются в разных файлах, причём сначала - html-код, а потом уже всё остальное. Правда, после получения html-кода браузер начинает запрашивать оставшиеся ресурсы параллельно, так что можно оценить время загрузки html-кода как 50% от общего времени получения данных. Итак, в нашем распоряжении осталось не более 1,5*0,5 = 0,75 секунды на обработку одного запроса. Если в среднем один поток обрабатывает запрос за 0,3 секекунды, то в очереди должно быть 0,75/0,3 = 2,5 запроса на поток. Так как у нас 8 рабочих потоков, то результирующий размер очереди должен составлять 2,5*8 = 20 запросов. Хочется отметить условность приведенных расчетов - при наличии конкретного сайта используемые в расчете величины можно определить гораздо точнее, но всё же он дает отправную точку для более оптимальной настройки производительности.

Итак, мы получили дескриптор сокета, после этого необходимо выделить память под структуру запроса. Описание этой структуры следующее:
typedef struct FCGX_Request { int requestId; int role; FCGX_Stream *in; FCGX_Stream *out; FCGX_Stream *err; char **envp; struct Params *paramsPtr; int ipcFd; int isBeginProcessed; int keepConnection; int appStatus; int nWriters; int flags; int listen_sock; int detached; } FCGX_Request;
Внимание! После получения нового запроса все предыдущие данные будут утеряны, поэтому при необходимости длительного хранения данных применяйте глубокое копирование (копируйте сами данные, а не указатели на данные).
Вы должны знать об этой структуре следующее:
- переменные in, out и err играют роль соответственно потоков ввода, вывода и ошибок. Поток ввода содержит данные POST-запроса, в поток вывода нужно отправить ответ FastCGI-программы (например, http-заголовки и html-код веб-страницы), а поток ошибок просто добавит запить в лог ошибок веб-сервера. При этом потоком ошибок можно вообще не пользоваться - если Вам действительно нужно логгировать ошибки, то, пожалуй, для этого лучше использовать отдельный файл - передача данных по сети и их последующая обработка веб-сервером потребляет дополнительные ресурсы.
- переменная envp содержит значения переменных окружения, устанавливаемых веб-сервером, и http-заголовки, например: SERVER_PROTOCOL, REQUEST_METHOD, REQUEST_URI, QUERY_STRING, CONTENT_LENGTH, HTTP_USER_AGENT, HTTP_COOKIE, HTTP_REFERER и так далее. Эти заголовки определяются соответственно стандартами CGI и HTTP протоколов, примеры их использования можно найти в любой CGI-программе. Сами данные хранятся в массиве строк, при этом последний элемент массива содержит нулевой указатель (NULL) в качестве обозначения конца массива. Каждая строка (каждый элемент массива строк) содержит одно значение переменной в формате НАЗВАНИЕ_ПЕРЕМЕННОЙ=ЗНАЧЕНИЕ, например: CONTENT_LENGTH=0 (в данном случае означает, что у данного запроса нет POST-данных, так как их длина равна нулю). Если в массиве строк envp нет нужного Вам заголовка, значит он не был передан. Если Вы хотите получить все переданные FastCGI-программе значения переменных, просто прочитайте в цикле все строки массива envp до тех пор пока не встретите указатель на NULL.
Собственно, на этом с описанием этой структуры мы закончили - всё остальные переменные Вам не понадобятся.

Память выделили, теперь нужно выполнить инициализацию структуры запроса:
int FCGX_InitRequest(FCGX_Request *request, int sock, int flags);
Параметры функции следующие:
request - указатель на структуру данных, которую нужно инициализировать
sock - дескриптор сокета, который мы получили после вызова функции FCGX_OpenSocket. Хочется отметить, что вместо уже готового дескриптора можно передать 0 (нуль) и получить сокет с настройками по умолчанию, но для нас данный способ совершенно не интересен - сокет будет открыт на случайном свободном порте, а, значит, мы не сможем правильно настроить наш веб-сервер - нам неизвестно заранее, куда именно нужно отправлять данные.
flags - флаги. Собственно, в эту функцию можно передать только один флаг - FCGI_FAIL_ACCEPT_ON_INTR - не вызывать FCGX_Accept_r при разрыве.

После этого нужно получить новый запрос:
int FCGX_Accept_r(FCGX_Request *request);
В неё нужно передать уже инициализированную на прошлом этапе структуру request. Внимание! В многопоточной программе необходимо использовать синхронизацию при вызове данной функции.
Собственно, эта функция выполняет всю работу по работе с сокетами: сначала она отправляет ответ веб-серверу на предыдущий запрос (если таковой был), закрывает предыдущий канал передачи данных и освобождает все связанные с ним ресурсы (в том числе - переменные структуры request), потом получает новый запрос, открывает новый канал передачи данных и подготавливает новые данные в структуре request для их последующей обработки. В случае ошибки получения нового запроса функция возвращает код ошибки, меньший нуля.

Далее Вам наверняка потребуется получить переменные окружения, для этого можно или самостоятельно обработать массив request->envp, или воспользоваться функцией
char *FCGX_GetParam(const char *name, FCGX_ParamArray envp);
где name - строка, содержащая название переменной окружения или http-заголовка, значение которого Вы хотите получить,
envp - массив переменных окружения, которые содержатся в переменной request->envp
Функция возвращает значение нужной нам переменной окружения в виде строки. Пусть внимательного читателя не пугает несоответствие типов между char ** и FCGX_ParamArray - эти типы объявлены синонимами (typedef char **FCGX_ParamArray).
Кроме того, Вам наверняка понадобится отправить ответ веб-серверу. Для этого нужно воспользоваться потоком вывода request->out и функцией
int FCGX_PutStr(const char *str, int n, FCGX_Stream *stream);
где str - буффер, содержащий данные для вывода, без завершающего нуля (то есть буффер может содержать двоичные данные),
n - длинна буффера в байтах,
stream - поток, в который мы хотим вывести данные (request->out или request->err).

Если Вы пользуетесь стандартами C-строками с завершающим нулём, удобнее будет использовать функцию
int FCGX_PutS(const char *str, FCGX_Stream *stream);
которая просто определит длину строки функцией strlen(str) и вызовет предыдущую функцию. Поэтому, если Вам заранее известна длина строки (например, Вы пользуетесь C++-строками std::string), лучше используйте предыдущую функцию по соображениям эффективности.
Хочется отметить, что эти функции прекрасно работают с UTF-8-строками, так что с многоязычными веб-прилодениями проблем быть не должно.
Вы так же можете вызывать эти функции несколько раз во время обработки одного и того же запроса, в ряде случаев это может повысить производительность. Например, Вам нужно отправить какой-то большой файл. Вместо того, чтобы загружать весь этот файл с жёсткого диска, а потом уже отправить его «одним куском», Вы можете сразу же начать отправлять данные. В результате клиент вместо белого экрана браузера начнёт получать интересующие его данные, что чисто психологически заставит его ещё немного подождать. Другими словами, Вы как бы выигрываете немного времени для загрузки страницы. Так же хочется отметить, что большинство ресурсов (каскадные таблицы стилей, JavaScript"ы и т.п.) указываются в начале веб-страницы, то есть браузер сможет проанализировать часть html-кода и начать загрузку этих ресурсов раньше - ещё один повод выводить данные по частям.

Следующее, что Вам может понадобиться - это обработать POST-запрос. Для того, что бы получить его значение, нужно прочитать данные из потока request->in при помощи функции
int FCGX_GetStr(char * str, int n, FCGX_Stream *stream);
где str - указатель на буффер,
n - размер буффера в байтах,
stream - поток, из которого мы читаем данные.
Размер передаваемых данных в POST-запросе (в байтах) можно определить с помощью переменной окружения CONTENT_LENGTH, значение которой, как мы помним, можно получить с помощью функции FCGX_GetParam. Внимание! Создавать буффер str на основании значения переменной CONTENT_LENGTH без каких-либо ограничений очень плохая идея: любой злоумышленник может отправить любой, сколь угодно большой POST-запрос, и у Вашего сервера может просто закончиться свободная оперативная память (получится DoS-атака, если хотите). Вместо этого лучше ограничить размер буффера какой-то разумной величиной (от нескольких килобайт до нескольких мегабайт) и вызывать функцию FCGX_GetStr несколько раз.

Последняя важная функция флеширует потоки вывода и ошибок (отправляет клиенту всё ещё не отправленные данные, которые мы успели поместить в потоки вывода и ошибок) и закрывает соединение:
void FCGX_Finish_r(FCGX_Request *request);
Хочется особо отметить, что эта функция не является обязательной: функция FCGX_Accept_r так же отправляет клиенту данные и закрывает текущее соединение перед получением нового запроса. Спрашивается: тогда зачем же она нужна? Представьте, что Вы уже отправили клиенту все необходимые данные, и сейчас Вам нужно выполнить какие-то завершающие операции: записать статистику в базу данных, ошибки в лог-файл и т.п. Очевидно, что соединение с клиентом уже больше не нужно, но клиент (в смысле, браузер) всё ещё ждёт от нас информацию: а вдруг мы отправим что-нибудь еще? При этом очевидно, что мы не можем вызвать FCGX_Accept_r раньше времени - после этого нужно будет начать обрабатывать следующий запрос. Как раз в этом случае Вам понадобится функция FCGX_Finish_r - она позволит закрыть текущее соединение до получения нового запроса. Да, мы сможем обработать такое же число запросов в единицу времени, как и без использования этой функции, но клиент получит ответ раньше - ему уже не придется ждать конца выполнения наших завершающих операций, а ведь именно из-за большей скорости обработки запросов мы и используем FastCGI.
На этом, собственно, заканчивается описание функций библиотеки и начинается обработка полученных данных.

Простой пример многопоточной FastCGI-программы

Думаю, в примере всё будет понятно. Единственное, печать отладочных сообщений и «засыпание» рабочего потока сделаны исключительно в демонстрационных целях. При компилировании программы не забудьте подключить библиотеки libfcgi и libpthread (параметры компилятора gcc: -lfcgi и -lpthread).

#include #include #include #include "fcgi_config.h" #include "fcgiapp.h" #define THREAD_COUNT 8 #define SOCKET_PATH "127.0.0.1:9000" //хранит дескриптор открытого сокета static int socketId; static void *doit(void *a) { int rc, i; FCGX_Request request; char *server_name; if(FCGX_InitRequest(&request, socketId, 0) != 0) { //ошибка при инициализации структуры запроса printf("Can not init request\n"); return NULL; } printf("Request is inited\n"); for(;;) { static pthread_mutex_t accept_mutex = PTHREAD_MUTEX_INITIALIZER; //попробовать получить новый запрос printf("Try to accept new request\n"); pthread_mutex_lock(&accept_mutex); rc = FCGX_Accept_r(&request); pthread_mutex_unlock(&accept_mutex); if(rc < 0) { //ошибка при получении запроса printf("Can not accept new request\n"); break; } printf("request is accepted\n"); //получить значение переменной server_name = FCGX_GetParam("SERVER_NAME", request.envp); //вывести все HTTP-заголовки (каждый заголовок с новой строки) FCGX_PutS("Content-type: text/html\r\n", request.out); //между заголовками и телом ответа нужно вывести пустую строку FCGX_PutS("\r\n", request.out); //вывести тело ответа (например - html-код веб-страницы) FCGX_PutS("\r\n", request.out); FCGX_PutS("\r\n", request.out); FCGX_PutS("\r\n", request.out); FCGX_PutS("\r\n", request.out); FCGX_PutS("

FastCGI Hello! (multi-threaded C, fcgiapp library)

\r\n", request.out); FCGX_PutS("

Request accepted from host ", request.out); FCGX_PutS(server_name ? server_name: "?", request.out); FCGX_PutS("

\r\n", request.out); FCGX_PutS("\r\n", request.out); FCGX_PutS("\r\n", request.out); //"заснуть" - имитация многопоточной среды sleep(2); //закрыть текущее соединение FCGX_Finish_r(&request); //завершающие действия - запись статистики, логгирование ошибок и т.п. } return NULL; } int main(void) { int i; pthread_t id; //инициализация библилиотеки FCGX_Init(); printf("Lib is inited\n"); //открываем новый сокет socketId = FCGX_OpenSocket(SOCKET_PATH, 20); if(socketId < 0) { //ошибка при открытии сокета return 1; } printf("Socket is opened\n"); //создаём рабочие потоки for(i = 0; i < THREAD_COUNT; i++) { pthread_create(&id[i], NULL, doit, NULL); } //ждем завершения рабочих потоков for(i = 0; i < THREAD_COUNT; i++) { pthread_join(id[i], NULL); } return 0; }

Простой пример конфигурации Nginx

Собственно, простейший пример конфига выглядит так:

Server { server_name localhost; location / { fastcgi_pass 127.0.0.1:9000; #fastcgi_pass unix:/tmp/fastcgi/mysocket; #fastcgi_pass localhost:9000; include fastcgi_params; } }

В данном случае этого конфига достаточно для корректной работы нашей FastCGI-программы. Закоментированные строчки - это пример работы с соответственно доменными сокетами Unix и заданием доменного имени хоста вместо IP-адреса.
После компиляции и запуска программы, и настройки Nginx у меня по адресу localhost появилась гордая надпись:
FastCGI Hello! (multi-threaded C, fcgiapp library)

Спасибо всем, кто дочитал до конца.

Когда пользователь заполняет html-форму и нажимает кнопку submit, данные отправляются веб-серверу. Веб-сервер, будь это Apache, IIS или какой-либо другой, запускает программу, указанную в качестве значения атрибута action. В нашем случае это test.cgi. Веб-сервер запускает test.cgi и передает ей параметры в виде текстовой строки, следующего содержания: name1=value1&name2=value2&....nameN=valueN, т.е. имя_параметра=значение. Эта строка передается на стандартный поток ввода (STDIN) или в качестве значения переменной окружения QUERY_STRING. Соответственно, считать данную строку в программе можно одним из двух способов:

В первом случае параметры передаются методом POST, а во втором методом GET. В первом случае мы читаем строку из STDIN. Длину строки мы узнаем из значения параметра окружения CONTENT_LENGTH. Во втором она хранится в переменной окружения QUERY_STRING. Значение переменной окружения можно получить, вызвав функцию getenv. Метод, с помощью которого передается строка с параметрами CGI-программе, можно определить следующим образом: strcmp(getenv("REQUEST_METHOD"),"POST"). Далее придется разбирать строку и получать необходимые значения параметров. Для того чтобы не делать это каждый раз, мы написали небольшую, но очень удобную библиотечку ITCGI для написания CGI-скриптов. Эта библиотека позволяет вам полностью абстрагироваться от метода, которым передаются параметры, от кодировки, от разбора строки. Вы просто вызываете функцию GetParamByName, в которую передаете имя интересующего вас параметра и адрес строки, куда сохранить значение. Библиотека также предоставляет вам ряд функций для написания эффективных и защищенных от взлома CGI-скриптов.
В простейшем случае, когда ваша программа не нуждается в параметрах, вам и не потребуется ни самому разбирать и раскодировать строку, ни использовать для этого нашу библиотеку. Самой простой CGI-программой будет: Заголовок является обязательной частью. Он передается веб-серверу и определяет, что следует за ним. В большинстве случаев у вас будет именно такой заголовок. Он говорит веб-серверу, что дальше идет HTML-код. С другими типами заголовков мы познакомимся чуть позже. В заголовке может быть несколько строк. Конец заголовка обозначается двумя переходами на новую строку - \n\n. Откомпилируйте эту программу, а исполняемый файл положите в каталог /cgi-bin вашего веб-сайта. Переименуйте его в test.cgi. К этому скрипту можно обратится непосредственно через обозреватель, написав в командной строке URL, например у меня это выглядит так http://сайт/cgi-bin/test.cgi В результате, в вашем обозревателе вы увидите строку: "Hello, World!".
Далее мы рассмотрим CGI-программу такого же типа. Она не принимает никаких параметров, но зато выдает более полезную информацию - список и значения всех переменных окружения. Такой скрипт вам пригодится, когда вы будете отлаживать свои CGI-программы на различных веб-серверах. Дело в том, что переменные окружения различаются на различных веб-серверах. Так, например, для веб-сервера Apache, путь к каталогу веб-сайта хранится в переменной окружения DOCUMENT_ROOT. Для веб-сервера Microsoft Internet Information Server это значение хранится в переменной PATH_TRANSLATED. В операционной системе UNIX скрипт для вывода всех переменных выглядит следующим образом.

#!/bin/sh echo "content-type: text/plain\n\n" echo env

Обратите внимание на CGI-заголовок. Он отличается от того, который у нас был в предыдущем примере. plain означает, что скрипт выдаст не HTML-код, а чистый текст. Броузер будет воспринимать его, как обычный текст и выводить в точности как есть. Здесь не надо заменять спецсимволы типа < на их эквиваленты <. Скопируйте этот скрипт в директорию /cgi-bin с именем env. Установите атрибут 755 (rwxr-xr-x). Вот результат выполнения такого скрипта на моем unix-сервере:

GATEWAY_INTERFACE=CGI/1.1 REMOTE_USER=itsoft REMOTE_ADDR=192.168.34.134 QUERY_STRING= REMOTE_PORT=1781 HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) DOCUMENT_ROOT=/usr/local/www/itsoft AUTH_TYPE=Basic SERVER_SIGNATURE= Apache/1.3.12 Server at itsoft..3.12 (Unix) PHP/3.0.17 HTTP_CONNECTION=Keep-Alive HTTP_COOKIE=/cgi-bin/authenticate.cgi_LAST=956345778 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin: /usr/local/bin:/usr/X11R6/bin HTTP_ACCEPT_LANGUAGE=ru SERVER_PROTOCOL=HTTP/1..226.32.34 SERVER_PORT=80 SCRIPT_NAME=/cgi-bin/web/env SERVER_NAME=сайт

Программа на языке Си для Windows и веб-сервера Internet Information Server будет выглядеть следующим образом:

#include #include void main() { char *text; char str; int length; FILE *in; sprintf(str,"command.com /c set>%s\\temp\\env.dmp",getenv("PATH_TRANSLATED")); system(str); sprintf(str,"%s\\temp\\env.dmp",getenv("PATH_TRANSLATED")); in = fopen(str, "rb"); if(!in) { printf("Content-type: text/plain\n\nCan"t open file %s.", str); return; } fseek(in, 0, SEEK_END); length = ftell(in); fseek(in, 0, SEEK_SET); text = (char*)malloc(length+1); fread(text, 1, length, in); text = 0; fclose(in); printf("Content-type: text/plain\n\n%s", text); free(text); }

Сначала выполняется команда command.com /c set>c:\www\mysite\temp\env.dmp. Результатом выполнения такой команды и будет список всех переменных окружения, который затем сохраняется в файл. Далее мы читаем этот файл и выдаем его содержимое веб-серверу. Вы можете заметить, что в данном случае, как и в прошлом примере, мы печатаем не html-код, а чистый текст и поэтому у нас заголовок: Content-type: text/plain. Не забудьте также, что этот cgi-скрипт будет работать только под Internet Information Server. Для веб-сервера Apache следует заменить getenv("PATH_TRANSLATED") на getenv("DOCUMENT_ROOT").
Ниже приведен результат действия этого скрипта на WindowsNT, вы можете видеть, какое количество параметров доступно через переменные окружения. Такой cgi-скрипт пригодится вам при настройке ваших скриптов на чужом сервере, где переменные окружения могут отличаться от ваших локальных. COMSPEC=C:\WINNT\SYSTEM32\COMMAND.COM COMPUTERNAME=JUPITER CONTENT_LENGTH=0 GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, applic HTTP_ACCEPT_LANGUAGE=ru HTTP_CONNECTION=Keep-Alive HTTP_HOST=www.oxygensoftware.com HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) HTTP_ACCEPT_ENCODING=gzip, deflate HTTPS=off INCLUDE=C:\Program Files\Mts\Include INSTANCE_ID=1410 LIB=C:\Program Files\Mts\Lib LOCAL_ADDR=168.144.29.178 NUMBER_OF_PROCESSORS=2 OS2LIBPATH=C:\WINNT\system32\os2\dll; OS=Windows_NT PATH=C:\WINNT\system32;C:\WINNT;C:\Program Files\Mts PATH_TRANSLATED=e:\InetPub\Clients\oxygensoftware.com PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.VBE;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 5 Stepping 1, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0501 PROMPT=$P$G REMOTE_ADDR=194.226.32.34 REMOTE_HOST=194.226.32.34 REQUEST_METHOD=GET SCRIPT_NAME=/cgi-bin/env.exe SERVER_NAME=www.oxygensoftware.com SERVER_PORT=80 SERVER_PORT_SECURE=0 SERVER_PROTOCOL=HTTP/1.1 SERVER_SOFTWARE=Microsoft-IIS/4.0 SYSTEMDRIVE=C: SYSTEMROOT=C:\WINNT TEMP=C:\temp TMP=C:\temp USERPROFILE=C:\WINNT\Profiles\Default User Далее, прежде чем перейти к рассмотрению cgi-скриптов, которые принимают и обрабатываю параметры формы, мы напишем простенькую программу, которая выдает строку параметров html-формы. О том, как считываются параметры формы, читайте выше, здесь я привожу исходный код программы и ее результат для html-формы, описанной в четвертой главе.

#include #include void main() { char* query=NULL; if(!strcmp(getenv("REQUEST_METHOD"),"POST")) { unsigned int len; len = atoi(getenv("CONTENT_LENGTH")); query = (char*)malloc(len+1); fread(query, 1, len, stdin); query = 0; } else if(!strcmp(getenv("REQUEST_METHOD"),"GET")) { query=(char*)malloc(strlen(getenv("QUERY_STRING"))); strcpy(query,getenv("QUERY_STRING")); } else printf("unknown REQUEST_METHOD\n"); printf("Content-type: text/plain\n\n%s", query); free(query); }

Скомпилируйте этот код. Он платформенно независимый, поэтому можете скомпилировать как под Unix, так и под Windows. Из четвертой главы возьмите HTML-форму, можете взять и любую другую. В поле action пропишите путь к данной программе на вашем веб-сервере. Результат после нажатия на кнопку "Опубликовать":
text=zero&text=zero&list=0&list2=0&textarea=%C7%E4%E5%F1%FC+%F2%E5%EA%F1%F2+%EF%EE+%F3%EC%EE%EB%F7%E0%ED%E8%FE

Это строка, которая содержит список всех параметров Далее, вы можете воспользоваться нашей библиотекой ITCGI или же самим разбирать эту строку параметров. О библиотеке и ее практическом использовании читайте в следующей параграфе.