Общий шлюзовый интерфейс (CGI). Простой пример конфигурации Nginx. Принцип работы CGI

Благодаря Всемирной паутине, почти любой может дать информацию в Интернете в приятном для глаз и пригодном для широкого распространения виде. Вы несомненно путешествовали по Интернету и видели другие сайты, и теперь вероятно знаете, что пугающие сокращения типа "HTTP" и "HTML" - просто своеобразные сокращения для "Веб" и "способ выражения информацим в Интернете". Возможно у Вас уже есть некоторый опыт представления информации в Интернете.

Интернет доказал, что является идеальной средой для распределения информации, как видно по его огромной популярности и масштабного развития. Хотя кое-кто подвергает сомнению полезность Интернета и приписывают ее широкое развитие и популярность главным образом навязчивой рекламе, Интернет бесспорно является важным средством представления всевозможных видов информации. Мало того, что существует множество услуг по предоставлению самой свежей информации (новости, погода, спортивные события в реальном времени) и материалов справочного характера в электронном виде, предлагаются также значительные объемы данных другого рода. Налоговое управление США, которое распространило все свои бланки налоговых деклараций в 1995 году и другую информацию через Всемирную паутину, недавно призналось о получении писем от поклонников своего Веб-сайта. Кто бы мог подумать, что Налоговое управление когда-нибудь будет получать письма от поклонников? Это произошло не от того, что его сайт был хорошо оформлен, а потому что он оказался по-настоящему полезным инструментом для тысяч, а возможно и миллионов людей.

Что делает Веб уникальным и таким привлекательным информационным сервисом? Прежде всего тем, что он предоставляет интерфейс гиперсреды для данных. Вспомните дисковод жесткого диска своего компьютера. Как правило, данные выражаются в линейном виде, аналогично файловой системе. Например, Вы имеете ряд папок, а внутри каждой папки находятся либо документы либо другие папки. Веб использует разную парадигму для выражения информации называемой гиперсредой. Гипертекстовый интерфейс состоит из документа и связей. Связи - это слова, на которые кликают, чтобы увидеть другие документы или отыскать другие виды информации. Веб расширяет концепцию гипертекста, включив другие типы носителей, например графику, звуки, видео (отсюда имя "гиперсреда"). Выделение текста или графики на документе позволяет увидеть связанную информацию о выделенном элементе в любом количестве форм.

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

Хотя Веб предоставляет для информации уникальный интерфейс гиперсреды, имеется много других эффективных способов распределения данных. Например, сетевые услуги типа Протокола передачи файлов (FTP) и группа новостей "Gopher" существовали намного раньше появления Всемирной паутины. Электронная почта была первичной средой для связи и обмена информацией по Интернету и большинством других сетей почти с самого начала функционирования этих сетей. Почему Интернет стал таким популярным способом распределения информации? Мультимедийный аспект Интернета внес ощутимый вклад в его небывалый успех, но для того, чтобы Интернет стал наиболее эффективным он должен быть интерактивным.

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

Термин "сервер Веб" может ввести в заблуждение, потому что он может относиться и к физической машине и программному обеспечению, используемому в ней для взаимодействия с Интернет-браузерами. Когда браузер запрашивает заданный адрес Веб, он сначала подключается к машине через Интернет, посылая программному обеспечению Веб-сервера запрос о документе. Это программное обеспечение работает непрерывно, ожидая поступления таких запросов и отвечая соответствующим образом.

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

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

Что такое CGI?

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

Обычно, для расширения возможностей сервера, Вам пришлось бы самому модифицировать сервер. Такое решение нежелательно, потому что это требует понимания нижнего уровня сетевого программирования по протоколу Интернета. Это также требовало бы редактирования и перекомпиляции исходного кода сервера или записи пользовательского сервера для каждой задачи. Допустим, нужно расширить возможности сервера так, чтобы он действовал как шлюз Web-to-e-mail (от Веб к эл.почте), отбирая информацию, введенную пользователем, из браузера и посылая ее по электронной почте другому пользователю. В сервер пришлось бы вставить код для анализа ввода от браузера, пересылки бы его по электронной почте другому пользователю, и пересылке ответа назад в браузер через сетевое соединение.

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

Во-вторых, это трудно и требует обширных технических знаний.

В-третьих, это применимо только для конкретного сервера. Если нужно переместить ваш сервер на другую платформу, придется запустить или по крайней мере потратить много времени, занимаясь переносом кода на эту платформу.

Почему CGI?

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

Связь CGI осуществляется стандартным вводом и выводом, что означает, что, если Вы знаете, как печатать и читать данные, используя свой язык программирования, можно написать приложение сервера Веб. Помимо анализа ввода и вывода, программирование приложений CGI почти эквивалентно программированию любого другого приложения. Например, для программирования программы "Hello, World!", используются функции печати вашего языка и формат, определенный для программ CGI, чтобы напечатать соответствующее сообщение.

Выбор языка програмирования

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

  • Печатать в стандартном выводе
  • Читать со стандартного ввода
  • Читать с переменных режимов

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

Языки подпадают под один из следующих двух классов: транслируемый и интерпретируемый. Транслируемый язык -например, C или C++ обычно меньше и быстрее, в то время как интерпретируемые языки, такие как Perl или Rexx, иногда требуют загрузки большого интерпретатора после запуска. Дополнительно, Вы можете распределять двоичные коды (код, транслируемый в машинный язык) без исходного кода, если ваш язык транслируемый. Распределение интерпретируемых сценариев обычно означает распределение исходнго кода.

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

Два наиболее часто используемых языка для программирования CGI - это C и Perl (оба из которых рассматриваются в настоящей книге). У обоих имеются четкие преимущества и недостатки. Perl - язык очень высокого уровня, и в то же время мощный язык, особенно пригодный для синтаксического анализа текста. Хотя легкость использования, гибкость, и мощность делает его языком, привлекательным для программирования CGI, его относительно большой размер и более медленная работа иногда делает его неподходящим для некоторых приложений. Программы C меньше по размеру, более эффективны и обеспечивают контроль за системой более низкого уровня, но более сложны для программирования, не имеют легких встроенных подпрограмм обработки текста, и их труднее отладить.

Какой язык является наиболее подходящим для программирования CGI? Тот, который Вы считаете для себя более удобным с точки зрения программирования. Оба одинаково эффективны для программирования приложений CGI, и с надлежащими библиотеками, оба имеют схожие возможности. Однако, если Вы имеете труднодоступный сервер, можно использовать меньшие транслируемые программы C. Если Вы должны быстро написать приложение, которое требует значительной работы по обработке текста, можно вместо него использовать Perl.

Предостережения

Имеются некоторые важные альтернативы к приложениям CGI. Много серверов теперь включают API-программирование, которое облегчает программирование прямых расширений сервера в противоположность отдельным приложениям CGI. Серверы API обычно более эффективны, чем программы CGI. Другие серверы включают встроенные функциональные возможности, которые могут обрабатывать специальные элементы без CGI, например, сопряжение баз данных. И наконец, некоторые приложения могут быть обработаны некоторыми новыми клиентскими (а не серверными) технологиями типа Java. Быстро ли устареет CGI в условиях таких быстрых изменений в технологии,?

Вряд ли. CGI имеет несколько преимуществ перед более новыми технологиями.

  • Он универсален и переносим. Вы можете написать приложение CGI, используя практически любой язык программирования на любой платформе. Некоторые из альтернатив, такие как API сервера, ограничивают Вас некоторыми языками и намного сложны для изучения.
  • Маловероятно что, клиентские технологии типа Java, заменят CGI, потому что имеются некоторые приложения, для которых серверные приложения намного лучше подходят для выполнения.
  • Многие из ограничений CGI - это ограничения HTML или HTTP. По мере развития стандартов Интернета в целом, развиваются и возможности CGI.

Резюме

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

Глава 2. Основы

Несколько лет назад, я создавал для колледжа в Гарварде страницу, куда бы можно было представлить свои комментарии о них. В то время, Интернет был молод, а документации было мало. Я, подобно многим другим, опирался на краткую документацию и систему программирования, созданную другими, чтобы научиться программированию CGI. Хотя этот метод изучения потребовал определенного поиска, множества экспериментов, и создавал много вопросов, он был очень эффективным. Настоящая глава - плод моей работы с CGI на ранних этапах (с несколькими уточнениями, разумеется).

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

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

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

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

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

  • Традиционная программа " Hello, World!";
  • Вывод CGI: отсылка информации назад для отображения в Интернет-браузере;
  • Конфигурирование, установка, и выполнение приложения. Вы узнаете о различных платформах и серверах Веб;
  • Ввод CGI: интерпретация информации, посланной браузером Веб. Ознакомление с некоторыми полезными библиотеками программирования для анализа такого ввода;
  • Простой пример: он охватывает все уроки данной главы;
  • Стратегия программирования.

Из-за характера данной главы, я только слегка касаюсь некоторых тем. Не волнуйтесь; все эти темы рассматриваются гораздо глубже в других главах.

Hello, World!

Вы начинаете с традиционной вводной задачи программирования. Вы напишете программу, которая отобразит "Hello, World!" на вашем браузере Веб. Прежде, чем написать эту программу, Вы должны понять, какую информацию браузер Веб ожидает получить от программ CGI. Вы также должны знать, как выполнить эту программу, так чтобы увидеть ее в действии.

CGI независит от языка, так что Вы можете реализовать эту программу на любом языке. Здесь используется несколько различных языков, чтобы продемонстрировать независимость каждого языка. В языке Perl, программа " Hello,World!" показана в листинге 2.1.

Листинг 2.1. Hello, World! в Perl. #!/usr/local/bin/perl # Hello.cgi - Моя первая программа CGI print "Content-Type: text/html\n\n"; print " \n"; print "Hello, World!"; print "\n"; print "\n"; print "

Hello, World!

\n"; print " \n";

Сохраните эту программу как hello.cgi, и установите ее в соответствующем месте. (Если Вы не уверены, где оно находится, не беспокойтесь; Вы узнаете это в разделе "Установка и выполнение программы CGI " ниже в данной главе.) Для большинства серверов нужный каталог называется cgi-bin. Теперь, вызовите программу из вашего браузера Веб. Для большинства, это означает открыть следующий универсальный указатель ресурса (URL):

http://hostname/directoryname/hello.cgi

Hostname - имя вашего сервера Веб, и directoryname - каталог, в который Вы помещаете hello.cgi (вероятно cgi-bin).

Разбиение hello.cgi

Следует отметить несколько моментов относительно hello.cgi.

Во-первых, вы используете простые команды печати. Программы CGI не требуют никаких специальных дескрипторов файла или описателей вывода. Чтобы послать вывод браузеру, просто печатают на stdout.

Во-вторых, обратите внимание на то, что содержание первого оператора печати (Content-Type: text/html) не появляется на вашем браузере Веб. Вы можете отослать любую информацию, по Вашему усмотрению, назад на браузер (страницу HTML, графику или звук), но сначала, нужно сообщить браузеру какого вида данные вы ему посылаете. Эта строка сообщает браузеру какой вид информации ожидать - в данном случае, страницу HTML.

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

В общем, hello.cgi состоит из двух основных частей:

  • сообщает браузеру какую информацию ожидать (Content-Type: text/html)
  • сообщает браузеру, что отобразить (Hello, World!)

Hello, World! в C

Чтобы показать независимость программ CGI от языков, в листинг 2.2 показан эквивалент программы hello.cgi , написанной в C.

Листинг 2.2. Hello, World! в C. /* hello.cgi.c - Hello, World CGI */ #include int main() { printf("Content-Type: text/html\r\n\r\n"); printf(" \n"); printf("Hello, World!\n"); printf("\n"); printf("\n"); printf("

Hello, World!

\n"); printf(" \n"); }

Примечание

Обратите внимание на то, что версия Perl hello.cgi использует Content-Type print ": text/html\n\n "; В то время как версия C использует Printf (" Content-Type: text/html\r\n\r\n ");

Почему Perl печатает операторный конец с двумя символами новой строки (\n), в то время как C printf заканчивается двумя символами возврата каретки и новой строки(\r\n)?

Формально, заголовки (весь вывод перед пустой строкой) как предполагается, будут отделены символом возрата каретки и новой строки. К сожалению, на машинах DOS и Windows, Perl транслирует \r как другую новую строку, а не как перевод каретки.

Хотя исключение \rs в Perl технически неправильно, она будет работать почти во всех протоколах и так же переноситься всеми платформами. Поэтому, во всех примерах Perl в этой книге я использую новую строку, отделяющие заголовки, а не символы возврата каретки и новой строки.

Соответствующее решение этой проблемы представлено в Главе 4, "Вывод".

Ни серверу Веб, ни браузеру не важно, какой язык используется для записи программы. Хотя каждый язык имеет преимущества и недостатки в качестве языка программирования CGI, лучше использовать язык, с которым Вам удобнее всего работать. (Более детально выбор языка программирования обсуждается в Главе 1 "Общешлюзовой интерфейс (CGI) ").

Выведение CGI

Теперь можно внимательнее изучить вопрос отправки информации на браузер Веб. Из примера " Hello, World!", видно, что браузеры Веб ожидают два набора данных: заголовок, который содержит информацию, например какую информацию отобразить (например Content-Type: line) и фактическую информацию (что отображается на браузере Веб). Эти два блока информации отделены пустой строкой.

Заголовок называется заголовком HTTP. Он дает важные сведения об информации, которую браузер собирается получать. Имеются несколько различных типов заголовков HTTP, и наиболее универсальным является тот, который Вы использовали раньше: Content-Type: заголовок. Вы можете использовать различные комбинации заголовков HTTP, отделяя их символами возврата каретки и новой линии (\r\n). Пустая строка, отделяющая заголовок от данных, также состоит из возврата каретки и новой строки (почему нужны оба, кратко описано в предшествующем примечании и подробно в Главе 4). Вы узнаете о других заголовках HTTP в Главе 4; в данный момент Вы занимаетесь Content-Type: заголовок.

Content-Type: заголовок описывает тип данных, которые возвращает CGI. Соответствующим форматом для этого заголовка является:

Content-Type: subtype/type

Где subtype/type - правильный тип многоцелевых расширений почты Интернета (MIME). Наиболее распространенным типом MIME является тип HTML: text/html. В таблице 2.1 приведено еще несколько распространненых типов MIME, которые будут рассмотрены; более полный перечень и анализ типов MIME приводится в Главе 4.

Примечание

MIME было первоначально изобретено для описания содержания тел сообщений почты. Оно стало довольно распространненым способом представления информации о Content-Type . Вы можете узнать больше о MIME в RFC1521. RFCs в Интернете обозначают "Просьбы о комментариях", которые представляют собой резюме решений, принятых группами в Интернете, пытающимися установить стандарты. Можно посмотреть результаты RFC1521 на следующем адресе: http://andrew2.andrew.cmu.edu/rfc/rfc1521.html

Таблица 2.1. Некоторые общие типы MIME. Тип MIME Описание Text/html Язык разметки гипертекста (HTML) Text/plain Простые текстовые файлы Image/gif Графические файлы GIF Image/jpeg Сжатые графические файлы JPEG Audio/basic Аудио - файлы Sun *.au Audio/x-wav Файлы Windows *.wav

После заголовка и пустой строки, Вы просто печатаете данные в нужном для Вас виде. Если Вы посылаете HTML, то печатайте теги HTML и данные к stdout после заголовка. Вы можете послать также графику, звук и другие двоичные файлы, просто печатая содержимое файла в stdout. Несколько примеров этого приведено в Главе 4.

Установка и выполнение программы CGI

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

Все серверы требуют пространства для файлов сервера и пространства для документов HTML. В настоящей книге, область сервера называется ServerRoot, а область документа - DocumentRoot. На машинах UNIX ServerRoot - обычно в /usr/local/etc/httpd/, а DocumentRoot - обычно в /usr/local/etc/httpd/htdocs/. Однако, это не имеет никакого значения для вашей системы, поэтому замените все ссылки на ServerRoot и DocumentRoot на ваши собственные ServerRoot и DocumentRoot.

Когда Вы обращаетесь к файлам, используя ваш браузер Веб, Вы определяете файл в URL относительно DocumentRoot. Например, если адрес вашего сервера mymachine.org, то Вы обращаетесь к этому файлу со следующим URL: http://mymachine.org/index.html

Конфигурирование сервера для CGI

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

  • Обозначенный каталог. Некоторые серверы позволяют определить, что все файлы в обозначенном каталоге (обычно, по умолчанию, называемый cgi-bin) являются CGI.
  • Расширения имени файла. Много серверов имеют такую предварительную конфигурацию, которая позволяет определять все файлы заканчивающиеся на.cgi, как CGI.

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

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

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

Предостережение

Помните о важности вопросов защиты, когда Вы конфигурируете ваш сервер для CGI. Некоторые подсказки будут рассмотрены здесь, а в Главе 9 "Защита CGI" эти аспекты рассматриваются более подробно.

Установка CGI на серверах UNIX

Независимо от того, как конфигурирован ваш сервер UNIX, нужно предпринять несколько шагов, чтобы удостовериться в том, что ваши приложения CGI выполняются должным образом. Ваш сервер Веб обычно будет работать как несуществующий пользователь (то есть пользователь UNIX nobody - учетная запись, которая не имеет прав доступа к файлу и не может быть зарегистрирована). Сценарии CGI (написанные на Perl, оболочке Bourne или на другом языке описания сценария) должны быть, выполнимы и читаемы по всему миру.

Подсказка

Чтобы сделать ваши файлы читаемыми и выполнимым по всему миру, используйте следующую команду UNIX права доступа: chmod 755 имени файла.

Если Вы используете язык описания сценария типа Perl или Tcl, укажите полный путь вашего интерпретатора в первой строке вашего сценария. Например, сценарий Perl, использующий perl в каталоге /usr/local/bin должен начинаться со следующей строки:

#!/usr/local/bin/perl

Предостережение

Никогда не помещайте интерпретатор (perl, или двоичный код Tcl Wish в каталог /cgi-bin. Это создает опасность для защиты в Вашей системе. Более подробно это описано в Главе 9.

Некоторые универсальные cерверы UNIX

Серверы NCSA и Apache имеют файлы со сходной конфигурацией, потому что сервер Apache был первоначально основан на коде NCSA. По умолчанию, они конфигурированы таким образом, чтобы любой файл в каталоге cgi-bin (расположенный по умолчанию в ServerRoot) являлся программой CGI. Чтобы изменить местоположение каталога cgi-bin, можно отредактировать файл конфигурации conf/srm.conf. Форматом для конфигурирования этого каталога является

ScriptAlias fakedirectoryname realdirectoryname

где fakedirectoryname - псевдо-имя каталога (/cgi-bin), и realdirectoryname - полный путь, где программы CGI фактически сохранены. Вы можете конфигурировать более одного ScriptAlias, добавляя еще строки ScriptAlias.

Заданная по умолчанию конфигурация достаточна для потребностей большинства пользователей. Нужно отредактировать строку в файле srm.conf в любом случае, чтобы определить правильное realdirectoryname. Если, например, Ваши программы CGI расположены в /usr/local/etc/httpd/cgi-bin, строка ScriptAlias в вашем файле srm.conf должна походить на следующую:

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/

Чтобы обращаться или ссылаться на программы CGI, расположенные в этом каталоге, используется следующий URL:

Http://hostname/cgi-bin/programname

Где hostname - имя хозяина вашего сервера Веб, и programname - имя Вашего CGI.

Например, допустим, что Вы скопировали программу hello.cgi в Ваш каталог cgi-bin (например, /usr/local/etc/httpd/cgi-bin) на Вашем сервере Веб, называемом www.company.com. Чтобы обратиться к вашему CGI, используйте следующий URL: http://www.company.com/cgi-bin/hello.cgi

Если нужно конфигурировать сервер NCSA или Apache так, чтобы распознавать любой файл с расширением.cgi как CGI, нужно отредактировать два файла конфигурации. Сначала, в файле srm.conf, не комментируйте следующую строку:

AddType application/x-httpd-cgi .cgi

Это свяжет CGI типа MIME с расширением.cgi. Теперь, нужно изменить файл access.conf, чтобы можно было выполнить CGI в любом каталоге. Для этого, добавьте опцию ExecCGI к строке Option. Это будет выглядеть примерно как следующая строка:

Option Indexes FollowSymLinks ExecCGI

Теперь, любой файл с расширением.cgi считается CGI; обращайтесь к нему, как обращались бы к любому файлу на вашем сервере.

Сервер CERN конфигурирован так же, как и серверы Apache и NCSA. Вместо ScriptAlias, сервер CERN использует команду Exec. Например, в файле httpd.conf, Вы увидете следующую строку:

Exec /cgi-bin/* /usr/local/etc/httpd/cgi-bin/*

Другие серверы UNIX можно конфигурировать таким же способом; более подробно об этом описано в документации сервера.

Установка CGI на Windows

Большинство серверов, доступных для Windows 3.1, Windows 95 и Windows NT конфигурировано с помощью метода "расширение имени файла" для распознавания CGI. Вообще, изменение конфигурации сервера на базе Windows просто требует выполнения программы конфигурации сервера и внесения соответствующих изменений.

Иногда конфигурирование сервера для правильного выполнения сценарий (типа Perl) представляется сложным делом. В DOS или Windows, Вы не сможете определить интерпретатор на первой строке сценария, как это происходит при работе с UNIX. Некоторые серверы имеют заранее заданную конфигурацию, чтобы связать некоторые расширения имени файла с интерпретатором. Например, многие Веб-серверы Windows предполагают, что файлы, оканчивающиеся на.pl, являются сценариями Perl.

Если сервер не выполняет такой тип ассоциации файла, можно определить пакетный файл упаковщика, который вызывает как иинтерпретатор, так и сценарий. Как и с сервером UNIX, не устанавливайте интерпретатор ни в каталоге cgi-bin ни в каком-либо Веб-доступном каталоге.

Установка CGI на Macintosh

Две наиболее известные опции сервера для Macintosh - это WebStar StarNine и его предшественник MacHTTP. Оба распознают CGI по расширению имени файла.

MacHTTP понимает два различных расширения: .cgi и.acgi, который обозначает асинхронный CGI. Регулярные программы CGI, установленные на Macintosh (с расширением.cgi), будут поддерживать Веб-сервер в состоянии занятости, пока не закончится выполнение CGI, вынуждая сервер приостановить выполнение всех других запросов. Асинхронный CGI, с другой стороны, позволяет серверу принимать запросы даже во время своей работы.

Разработчик CGI Macintosh, использующий любой из этих Веб-серверов, должен, по возможности, использовать просто расширение.acgi, а не расширение.cgi. Оно должно работать с большинством программ CGI; если оно не работает, переименуйте программу на.cgi.

Выполнение CGI

После того, как вы установили CGI, имеются несколько способов выполнить его. Если ваш CGI -программа, работающая только с выводом, типа программы Hello,World!, тогда Вы может выполнять ее, просто обращаясь к ее URL.

Большинство программ выполняется как серверное приложение к форме HTML. Прежде, чем научиться, как получать информацию от этих форм, сначала прочтите краткое введение о создании таких форм.

Быстрая обучающая программа по формам HTML

Два наиболее важных тега в форме HTML - это теги

и . Можно создавать большинство форм HTML, используя только эти два тега. В данной главе, Вы изучите эти теги и небольшое подмножество возможных типов или атрибутов . Полное руководство и ссылка на формы HTML находятся в Главе 3 " HTML и формы" .

Тег

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

Следующая строка показывает спецификации для тега :

< ACTION FORM = "url" METHOD = ENCTYPE = "..." >

Атрибут ENCTYPE не играет особой роли и обычно не включается с тегом . Подробная информация относительно тега ENCTYPE дана в Главе 3. Один из способов использования ENCTYPE, показан в Главе 14 "Фирменные расширения. "

Атрибут ACTION ссылается на URL программы CGI. После того, как пользователь заполнит форму и предоставит информацию, вся информация кодируется и передается программе CGI. Программа CGI решает сама вопрос о декодировании и обработке информации; этот аспект рассматривается в "Принятие ввода от браузера, " ниже в настоящей главе.

Наконец, атрибут METHOD описывает, как программа CGI должна получать ввод. Эти два методы - GET и POST - отличаются в отношении того, как передавать информацию программе CGI. Оба обсуждены в "Принятие ввода от браузера. "

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

для обозначения конца формы. Нельзя иметь форму внутри формы, хотя Вы можете установить форму, которая позволяет представлять части информации в различные местах; этот аспект широко рассматривается в Главе 3.

Тег

Вы можете создавать полоски ввода текста, кнопки "radio", окна флажков, и другие средства принятия ввода, используя тег. В данном разделе рассматриваются только поля текстового ввода. Для реализации этого поля, используйте тег со следующими атрибутами:

< INPUT TYPE=text NAME = "... " VALUE = "... " SIZE = MAXLENGTH = >

NAME - символическое имя переменной, которая содержит значение, введенное пользователем. Если Вы включаете текст в атрибут VALUE, этот текст будет помещен как заданный по умолчанию в поле текстового ввода. Атрибут SIZE позволяет Вам определить горизонтальную длину поля ввода, поскольку он будет появляться в окне браузера. И наконец, MAXLENGTH определяет максимальное число символов которые, пользователь может ввести в поле. Обратите внимание, что атрибуты VALUE, SIZE, MAXLENGTH являются необязательными.

Представление формы

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

< Input type=submit >

Этот тег создает внутри вашей формы кнопку Submit. Когда пользователь закончивает заполнение формы, он или она может отправить ее содержание по адресу URL, указанному атрибутом ACTION формы, кликая кнопку Submit.

Принятие ввода от браузера

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

Программа CGI получает два вида информации от браузера.

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

Переменные среды

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

Таблица 2.2. Некоторые важные переменные среды CGI Переменная среды Цель REMOTE_ADDR Адрес IP машины клиента. REMOTE_HOST Хост хозяина машины клиента. HTTP _ACCEPT Перечисляет типы MIME данных, которые браузер умеет интерпретировать. HTTP _USER_AGENT Информация браузера (тип браузера, номер версии, операционная система, и т.д.). REQUEST_METHOD GET или POST. CONTENT_LENGTH Размер ввода, если он послан через POST. Если не имеется никакого ввода или если используется метод GET, этот параметр не определен. QUERY_STRING Содержит вводимую информацию, когда она передается с помощью метода GET. PATH_INFO Позволяет пользователю определить путь от командной строки CGI (например, http://hostname/cgi-bin/programname/path). PATH_TRANSLATED Транслирует относительный путь в PATH_INFO в фактический путь в системе.

Чтобы записать приложение CGI, которое отображает переменные среды, нужно знать, как выполнить две вещи:

  • Определить все переменные среды и их соответствующие значения.
  • Вывести результаты для браузера.

Вы уже знаете, как выполнять последнюю операцию. В Perl переменные среды сохраняются в ассоциативном массиве %ENV, который вводится именем переменной среды. Листинг 2.3 содержит env.cgi, программу Perl, которая служит для достижения нашей цели.

Листинг 2.3. Программа Perl, env.cgi, которая выводит все переменные среды CGI.

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

CGI Environment

\n"; foreach $env_var (keys %ENV) { print "$env_var = $ENV{$env_var}
\n"; } print " \n";

Подобная программа может быть написана в C; полный код находится в Листинге 2.4.

Листинг 2.4. Env.cgi.c в C. /* env.cgi.c */ #include extern char **environ; int main() { char **p = environ; printf("Content-Type: text/html\r\n\r\n"); printf(" \n"); printf("CGI Environment\n"); printf("\n"); printf("\n"); printf("

CGI Environment

\n"); while(*p != NULL) printf("%s
\n",*p++); printf(" \n"); }

GET или POST ?

Какая разница между методами GET и POST? GET передает закодированную входную строку через переменную среды QUERY_STRING, а POST передает ее через stdin. POST - более предпочтительный метод, особенно для форм с большим количеством данных, потому-что здесь нет каких-либо ограничений в отношении объема посылаемой информации, а при методе GET объем пространства среды ограничен. GET имеет однако определенное полезное свойство; это подробно рассматривается в Главе 5 "Ввод".

Чтобы определить, который метод используется, программа CGI проверяет переменную среду REQUEST_METHOD, которая будет установлена либо в GET, либо в POST. Если она установлена в POST, длина закодированной информации сохранена в переменной среды CONTENT_LENGTH.

Закодированный Ввод

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

Чтобы определить это, браузер использует кодирующую спецификацию URL, которая может быть описана следующим образом:

  • Отделяет различные поля амперсандом (&).
  • Отделяет имя и значения знаками равенства (=), с именем слева и значением справа.
  • Заменяет пробелы знаками "плюс" (+).
  • Заменяет все "ненормальные" символы знаком процента (%), за которым следует двузначный шестнадцатеричный код символа.

Ваша конечная закодированная строка будет похожа на следующую:

Name1=value1&name2=value2&name3=value3 ...

Примечание: Спецификации для кодирования URL находятся в RFC1738.

Например, предположим, что у вас была форма, которая запросила имя и возраст. Код HTML, который использовался для отображения этой формы, представлен в листинге 2.5.

Листинг 2.5. Код HTML для отображения формы имени и возраста.

Name and Age

Enter your name:

Enter your age:

Предположим, что пользователь вводит Joe Schmoe в поле имени, и 20 - в поле возраста. Ввод будет закодирован во входной строке.

Name=Joe+Schmoe&age=20

Синтаксический анализ ввода

Для того чтобы эта информация была полезной, нужно использовать информацию на что-то такое, что может быть использовано вашими программами CGI. Стратегии синтаксического анализа ввода рассматриваются в Главе 5. Практически, Вам никогда не придется думать о том, как анализировать ввод, потому что несколько специалистов уже написали доступные для всех библиотеки, которые производят синтаксический анализ. Две такие библиотеки представлены в настоящей главе в следующих разделах: cgi -lib.pl для Perl (написаны Стивом Бреннером) и cgihtml для C (написаны мной).

Общая цель большинства библиотек, написанных на различных языках, состоит в том, чтобы анализировать закодированную строку и помещать пары имен и значений в структуру данных. Имеется очевидное преимущество в использовании языка, который имеет встроенные структуры данных типа Perl; однако, большинство библиотек для языков низшего уровня типа C и C++ включает выполнение структуры данных и подпрограммы.

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

Cgi -lib.pl

Cgi -lib.pl использует ассоциативные массивы Perl. Функция &ReadParse анализирует входную строку и вводит каждую пару "имя / значение" по имени. Например, соответствующими строками Perl, необходимыми для декодирования только что представленной вводной строки "имя / возраст", были бы

&ReadParse(*input);

Теперь, чтобы увидеть значение, введенное для "имени", можно обращаться к ассоциативному массиву $input {"имя"}. Точно так же, чтобы обратиться к значению "возраста", нужно посмотреть на переменную $input {"возраст"}.

Cgihtml

C не имеет никаких встроенных структур данных, так что cgihtml осуществляет свой собственный список связей для использования со своими анализирующими подпрограммами CGI. Это определяет структуру entrytype следующим образом:

Typedef struct { Char *name; Char *value; } Entrytype;

Чтобы проанализировать вводную строку "name / age" ("имя / возраст") в C, используя cgihtml, используется следующее:

/* объявить связанный список, называемый вводом */ Llist input; /* анализировть ввод и место в связанном списке */ read_cgi_input(&input);

Чтобы обратиться к информации о возрасте, можно либо проанализировать список вручную, либо использовать имеющуюся функцию cgi _val ().

#include #include Char *age = malloc (sizeof (char) * strlen (cgi _val (input, "age")) + 1); Strcpy (age, cgi _val (input, "age"));

Значение "возраста" теперь сохранено в строке age.

Примечание: Вместо использования простого массива (подобно char age ;), я занимаюсь динамическим распределением пространства памяти для строки age. Хотя это усложняет программирование, тем не менее это важно с точки зрения безопасности. Более подробно о этом говорится в Главе 9.

Простая программа CGI

Вы собираетесь записать программу CGI, называемую nameage.cgi, которая обрабатывает форму "имя / возраст". Обработка данных (что я обычно называю "промежуточным материалом") минимальна. Nameage.cgi просто декодирует ввод и отображает имя пользователя и возраст. Хотя не особенно много пользы от такого инструмента, он демонстрирует наиболее критический аспект программирования CGI: ввод и вывод.

Вы используете ту же самую форму, как описано выше, вызывая поля "имя и возраст". Пока не стоит беспокоиться об ошибкоустойчивости и эффективности; решите имеющуюся задачу простейшим образом. Решения в Perl и C показаны соответственно в листингах 2.6 и 2.7.

Листинг 2.6. Nameage.cgi в Perl

#!/usr/local/bin/perl # nameage.cgi require "cgi-lib.pl" &ReadParse(*input); print "Content-Type: text/html\r\n\r\n"; print " \n"; print "Name and Age\n"; print "\n"; print "\n"; print "Hello, " . $input{"name"} . ". You are\n"; print $input{"age"} . " years old.

\n"; print " \n";

Листинг 2.7. nameage.cgi в C

/* nameage.cgi.c */ #include #include "cgi-lib.h" int main() { llist input; read_cgi_input(&input); printf("Content-Type: text/html\r\n\r\n"); printf(" \n"); printf("Name and Age\n"); printf("\n"); printf("\n"); printf("Hello, %s. You are\n",cgi_val(input,"name")); printf("%s years old.

\n",cgi_val(input,"age")); printf(" \n"); }

Обратите внимание на то, что эти две программы почти эквивалентны. Они обе содержат подпрограммы синтаксического анализа, которые занимают только одну строку и обрабатывают весь ввод (благодаря соответствующим библиотечным подпрограммам). Вывод, по существу, является измененной версией вашей основной программы Hello, World!.

Попытайтесь выполнить программу, заполняя форму и нажимая кнопку Submit.

Общая стратегия программирования

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

  • Простота
  • Эффективность
  • Универсальность

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

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

Резюме

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

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

Глава №9 .

Программирование с использованием CGI

Включение раздела о CGI в книгу по базам данных может показаться столь же странным, как если бы в кулинарную книгу была включена глава о ремонте автомобилей. Разумеется, для того чтобы съездить в магазин за продуктами, нужен исправный автомобиль, но уместно ли об этом говорить? Полное изложение CGI и веб-программирование в целом выходят за рамки данной книги, но краткого введения в эти темы достаточно для того, чтобы расширить возможности MySQL и mSQL по представлению данных в царстве Web.

В основном эта глава предназначена тем, кто изучает базы данных, но не прочь приобрести некоторые знания и в программировании для Web. Если ваша фамилия Бернерс-Ли или Андрессен, вряд ли вы найдете здесь то, чего еще не знаете. Но даже если вы не новичок в CGI, наличие под рукой краткого справочника во время погружения в тайны MySQL и mSQL может оказаться весьма полезным.

Что такое CGI?

Как и большинство акронимов, Common Gateway Interface (CGI - общий шлюзовый интерфейс) мало что говорит по сути. Интерфейс с чем? Где этот шлюз? О какой общности речь? Чтобы ответить на эти вопросы, вернемся немного назад и бросим взгляд на WWW в целом.

Тим Бернерс-Ли, физик, работавший в CERN, придумал Web в 1990 году, хотя план возник еще в 1988. Идея состояла в том, чтобы дать исследователям в области физики элементарных частиц возможность легко и быстро обмениваться мультимедийными данными - текстом, изображениями и звуком - через Интернет. WWW состояла из трех основных частей: HTML, URL и HTTP. HTML - язык форматирования, используемый для представления содержания в Web. URL - это адрес, используемый для получения содержимого в формате HTML (или каком-либо ином) с веб-сервера. И, наконец, HTTP - это язык, который понятен веб-серверу и позволяет клиентам запрашивать у сервера документы.

Возможность пересылки через Интернет информации всех типов явилась революцией, но вскоре была обнаружена и другая возможность. Если можно переслать через Web любой текст, то почему нельзя переслать текст, созданный программой, а не взятый из готового файла? При этом открывается море возможностей. Простой пример: можно использовать программу, выводящую текущее время, так, чтобы читатель видел правильное время при каждом просмотре страницы. Несколько умных голов в National Center for Supercomputing Applications (Национальный центр разработки приложений для суперкомпьютеров -NCSA), которые создавали веб-сервер, такую возможность увидели, и вскоре появился CGI.

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

Если CGI позволяет программам посылать данные клиенту, то формы расширяют эту возможность, позволяя клиенту посылать данные для этой CGI-программы. Теперь пользователь может не только видеть текущее время, но и устанавливать часы! Формы CGI открыли дверь для подлинной интерактивности в мире Web. Распространенные приложения CGI включают в себя:

  • Динамический HTML. Целые сайты могут генерироваться одной CGI-программой.
  • Поисковые механизмы, находящие документы с заданными пользователем словами.
  • Гостевые книги и доски объявлений, в которые пользователи могут добавлять свои сообщения.
  • Бланки заказов.
  • Анкеты.
  • Извлечение информации из размещенной на сервере базы данных.

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

Формы HTML

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

<НТМL><НЕАD><ТITLЕ>Моя страница с формами


<р>Это страница с формой.


Введите свое имя:



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


Этот тег указывает на начало формы. В конце формы требуется закрывающий тег

. Между тегами
допускаются три атрибута: ACTION задает URL или относительный путь к CGI-програм-ме, которой будут посланы данные; METHOD указывает метод HTTP, посредством которого будет послана форма (это может быть GET или ч POST, но мы почти всегда будем использовать POST); ENCTYPE задает метод кодирования данных (его следует использовать только при четком понимании того, что вы делаете).


Предоставляет наиболее гибкий способ ввода данных пользователем. Фактически есть девять разных типов тега . Тип задается атрибутом TYPE. В предыдущем примере используются два тега : один с типом SUBMIT и другой с типом по умолчанию TEXT. Девять типов следующие:

TEXT

Поле для ввода пользователем одной строки текста.

PASSWORD

To же, что TEXT, но вводимый текст не отображается на экране.

CHECKBOX

Флажок, который пользователь может устанавливать и сбрасывать.

RADIO

Радиокнопка, которая должна объединяться еще хотя бы с одной радиокнопкой. Пользователь может выбрать только одну из них.

SUBMIT

Кнопка, при нажатии которой форма отправляется на веб-сервер.

RESET

Кнопка, при нажатии которой в форме восстанавливаются значения по умолчанию.

FILE

Аналогичен текстовому окну, но предполагает ввод имени файла, который будет отправлен на сервер.

HIDDEN

Невидимое поле, в котором могут храниться данные.

IMAGE

Аналогичен кнопке SUBMIT, но можно задать картинку для изображения на кнопке.

Кроме атрибута TYPE теги обычно имеют атрибут NAME, связывающий введенные в поле данные с некоторым именем. Имя и данные передаются серверу в стиле величина=значение. В предыдущем примере текстовое поле именовалось firstname . Можно использовать атрибут VALUE, чтобы присвоить полям типа TEXT, PASSWORD , FILE и HIDDEN предустановленные значения. Этот же атрибут, используемый с кнопками типа SUBMIT или RESET, выводит на них заданный текст. Поля типа RADIO и CHECKBOX можно отобразить как выставленные с помощью атрибута CHECKED без задания значения.

Атрибут SIZE используется для задания длины полей типа TEXT, PASSWORD и FILE. Атрибут MAXLENGTH можно использовать для ограничения длины вводимого текста. Атрибут SRC задает URL изображения, используемого в типе IMAGE. И наконец, атрибут ALIGN задает характер выравнивания изображения для типа IMAGE и может иметь значение TOP, MIDDLE, BOTTOM (по умолчанию), LEFT или RIGHT (вверх, в середину, вниз, влево, вправо).

.

Как и у тега , у тега , и в качестве текста по умолчанию будет принят любой текст, находящийся между тегами , аналогично атрибуту VALUE для тега . Для тега

, дающая место для ввода очерка. Данные получают имя "essay". Блок текста 70 символов в ширину и 10 строк в глубину. Пространство между тегами

можно использовать для образца очерка. -->

типов "SUBMIT" и "RESET" соответственно. Кнопка "SUBMIT" имеет переопределенную надпись "Ввести данные ", а кнопка "RESET" имеет надпись по умолчанию (определяемую броузером). Кликнув по кнопке "SUBMIT", вы пошлете данные на веб-сервер, Кнопка "RESET" восстановит данные R исходное состояние, удалив все введенные пользователем данные. -->


Единственный тип ввода, который мы здесь не использовали, - это тип IMAGE для тега . Можно было бы использовать его в качестве альтернативного способа отправки формы. Однако тип IMAGE редко совместим с текстовыми и не очень чуткими броузерами, поэтому благоразумно избегать его, если только ваш сайт не выполнен в насыщенном графическом стиле.

После знакомства с основами форм HTML можно приступить к изучению собственно CGI.

Спецификация CGI

Итак, что в точности представляет собой «набор правил», позволяющий CGI-программе, скажем, в Батавии, штат Иллинойс, обмениваться данными с веб-броузером во Внешней Монголии? Официальную спецификацию CGI наряду с массой других сведений о CGI можно найти на сервере NCSA по адресу http://hoohoo . ncsa.uluc.edu/ cgi/. Однако эта глава для того и существует, чтобы вам не пришлось долго путешествовать и самому ее искать.

Есть четыре способа, которыми CGI передает данные между CGI-npor-раммой и веб-сервером, а следовательно, и клиентом Web:

  • Переменные окружения.
  • Командная строка.
  • Стандартное устройство ввода.
  • Стандартное устройство вывода.

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

Эти данные приводятся с прикидкой на сервер HTTP Apache. Apache - наиболее распространенный веб-сервер, работающий практически на любой платформе, включая Windows 9х и Windows NT. Однако они могут быть применимы ко всем HTTP-серверам, поддерживающим CGI. Некоторые патентованные серверы, например, от Microsoft и Netscape, могут иметь дополнительные функции или работать несколько иначе. Поскольку лицо Web продолжает изменяться с невероятной скоростью, стандарты все еще развиваются, и в будущем, несомненно, произойдут изменения. Однако, что касается CGI, то эта технология представляется устоявшейся - расплачиваться за это приходится тем, что другие технологии, такие как апплеты, ее потеснили. Все CGI-программы, которые вы напишете, используя эти сведения, почти наверное смогут работать еще долгие годы на большинстве веб-серверов.

Когда CGI-программа вызывается посредством формы - наиболее распространенного интерфейса, броузер передает серверу длинную строку, в начале которой стоит путь к CGI-программе и ее имя. Затем следуют различные другие данные, которые называются информацией пути и передаются CGI-программе через переменную окружения PATH_INFO (рис. 9-1). После информации пути следует символ «?», а за ним - данные формы, которые посылаются серверу с помощью метода HTTP GET. Эти данные становятся доступными CGI-программе через переменную окружения QUERY_STRING . Любые данные, которые страница посылает с использованием метода HTTP POST, который используется чаще всего, будут переданы CGI-программе через стандартное устройство ввода. Типичная строка, которую может получить сервер от броузера, показана на рис. 9-1. Программа с именем formread в каталоге cgi-bin вызывается сервером с дополнительной информацией пути extra/information и данными запроса choice=help - по-видимому, как часть исходного URL. Наконец, данные самой формы (текст «CGI programming» в поле «keywords») пересылаются через метод HTTP POST .

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

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

имеет доступ к этим переменным так же, как и к любым переменным среды командного процессора при запуске из командной строки. В сценарии командного процессора, например, к переменной окружения F00 можно обращаться как $F00; в Perl это обращение выглядит, как $ENV{"F00"} ; в С - getenv("F00") ; и т. д. В таблице 9-1 перечислены переменные, которые всегда устанавливаются сервером - хотя бы и в значение null. Помимо этих переменных данные, возвращаемые клиентом в заголовке запроса, присваиваются переменным вида HTTP_F00 , где F00 - имя заголовка. Например, большинство веб-броузеров включает данные о версии в заголовок с именем USEfl_AGENT . Ваша CGI-npor-рамма может получить эти данные из переменной HTTP_USER_AGENT .

Таблица 9-1. Переменные окружения CGI

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

Описание

CONTENT_LENGTH

Длина данных, переданных методами POST или PUT, в байтах.

CONTENT_TYPE

Тип MIME данных, присоединенных с помощью методов POST или PUT .

GATEWAY_INTERFACE

Номер версии спецификации CGI, поддерживаемой сервером.

PATH_INFO

Дополнительная информация пути, переданная клиентом. Например, для запроса http://www.myserver.eom/test.cgi/this/is/a/ path?field=green значением переменной РАТН_ INFO будет /this/is/a/path.

PATH_TRANSLATED

То же, что PATH_INFO , но сервер производит всю


Возможную трансляцию, например, расширение имен типа «-account». »

QUERY_STRING

Все данные, следующие за символом «?» в URL. Это также данные, передаваемые, когда REQ-UEST_METHOD формы есть GET.

REMOTE_ADDR

IP-адрес клиента, делающего запрос.

REMOTE_HOST

Имя узла машины клиента, если оно доступно.

REMOTE_IDENT

Если веб-сервер и клиент поддерживают идентификацию типа identd, то это имя пользователя учетной записи, которая делает запрос.

REQUEST_METHOD

Метод, используемый клиентом для запроса. Для CGI-программ, которые мы собираемся создавать, это обычно будет POST или GET.
SERVER_NAME Имя узла - или IP-адрес, если имя недоступно, -машины, на которой выполняется веб-сервер.
SERVER_PORT Номер порта, используемого веб-сервером.
SERVER_PROTOCOL
 Протокол, используемый клиентом для связи с сервером. В нашем случае этот протокол почти всегда HTTP.
SERVER_SOFTWARE Данные о версии веб-сервера, выполняющего CGI-программу.

SCRIPT_NAME

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

Приведем пример сценария CGI на Perl, который выводит все переменные окружения, установленные сервером, а также все унаследованные переменные, такие как PATH, установленные командным процессором, запустившим сервер.

#!/usr/bin/perl -w

print << HTML;

Content-type: text/html\n\n

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

HTML

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

print <

HTML

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

Командная строка

CGI допускает передачу CGI-программе аргументов в качестве параметров командной строки, которая редко используется. Редко используется она потому, что практические применения ее немногочисленны, и мы не будем останавливаться на ней подробно. Суть в том, что если переменная окружения QUERY_STRING не содержит символа « = », то CGI-программа будет выполняться с параметрами командной строки, взятыми из QUERY_STRING . Например, http://www.myserver.com/cgi- bin/finger?root запустит finger root на www.myserver.com.

Есть две основные библиотеки, обеспечивающие CGI-интерфейс для Perl. Первая из них - cgi-lib.pl Утилита cgi-lib.pl очень распространена, поскольку в течение долгого времени была единственной имеющейся большой библиотекой. Она предназначена для работы в Perl 4, но работает и с Perl 5. Вторая библиотека, CGI.pm, более новая и во многом превосходит cgi-lib.pl. CGI.pm написана для Perl 5 и использует полностью объектно-ориентированную схему для работы с данными CGI. Модуль CGI.pm анализирует стандартное устройство ввода и переменную QUERY_STRING и сохраняет данные в объекте CGI. Ваша программа должна лишь создать новый объект CGI и использовать простые методы, такие как paramQ, для извлечения нужных вам данных. Пример 9-2 служит короткой демонстрацией того, как CGI.pm интерпретирует данные. Все примеры на Perl в этой главе будут использовать CGI.pm.

Пример 9-2. Синтаксический анализ CGI-данных на Perl

#!/usr/bin/perl -w

use CGI qw(:standard);

# Используется модуль CGI.pm. qw(:standard) импортирует

# пространство имен стандартных CGI-функций,чтобы получить

# более понятный код. Это можно делать, если в сценарии

# используется только один объект CGI.

$mycgi = new CGI; #Создать объект CGI, который будет "шлюзом" к данным формы

@fields = $mycgi->param; # Извлечь имена всех заполненных полей формы

print header, start_html("CGI.pm test"); ft Методы "header" и "start_html",

# предоставляемые

# CGI.pm, упрощают получение HTML.

# "header" выводит требуемый заголовок HTTP, a

#"start_html" выводит заголовок HTML с данным названием,

#a также тег .

print "<р>Данные формы:
";

foreach (@fields) { print $_, ":",- $mycgi->param($_), "
"; }

# Для каждого поля вывести имя и значение, получаемое с помощью

# $mycgi->param("fieldname").

print end_html; # Сокращение для вывода завершающих тегов "".

Обработка входных данных в С

Поскольку основные API для MySQL и mSQL написаны на С, мы не будем полностью отказываться от С в пользу Perl, но там, где это уместно, приведем несколько примеров на С. Есть три широко используемые С-библиотеки для CGI-программирования: cgic Тома Бу-телла (Tom Boutell)*; cgihtml Юджина Кима (Eugene Kim)t и libcgi от EIT*. Мы полагаем, что cgic является наиболее полной и простой в использовании. В ней, однако, недостает возможности перечисления всех переменных формы, когда они не известны вам заранее. На самом деле, ее можно добавить путем простого патча, но это выходит за рамки данной главы. Поэтому в примере 9-3 мы используем библиотеку cgihtml, чтобы повторить на С приведенный выше сценарий Perl.

Пример 9-3. Синтаксический анализ CGI-данных на С

/* cgihtmltest.c - Типовая CGI-программа для вывода ключей и их значений

из данных, полученных от формы */

#include

#include "cgi-lib.h" /* Здесь содержатся все определения функций СGI */

#include "html-lib.h" /* Здесь содержатся" все определения вспомогательных функций для HTML */

void print_all(llist 1)

/* Эти функции выводят данные, переданные формой, в том же формате, что и приведенный выше сценарий Perl. Cgihtml предоставляет также встроенную функцию

Print_entries(), которая делает то же самое, используя формат списка HTML. */ {

node* window;

/* Тип "node" определен в библиотеке cgihtml и ссылается на связанный список, в котором хранятся все данные формы. */

window = I.head; /* Устанавливает указатель на начало данных формы */

while (window != NULL) { /* Пройти по связанному списку до последнего (первого пустого) элемента */

printf(" %s:%s
\n",window->entry. name,replace_ltgt(window->entry.value));

/* Вывести данные. Replace__ltgt() - функция, понимающая HTML-кодировку текста и обеспечивающая его правильный вывод на броузер клиента. */

window = window->next; /* Перейти к следующему элементу списка. */

} }

int main() {

llist entries; /* Указатель на проанализированные данные*/

int status; /* Целое число, представляющее статус */

Html__header(); /* Вспомогательная функция HTML, выводящая заголовок HTML*/

Html_begin("cgihtml test");

/* Вспомогательная функция HTML, выводящая начало страницы HTML с указанным заголовком. */

status = read_cgi_input(&entries); /* Производит ввод и синтаксический анализ данных формы*/

Printf("<р>Данные формы:
");

Print_all(entries); /* Вызывает определенную выше функцию print_all(). */

html_end(); /* Вспомогательная функция HTML, выводящая конец страницы HTML. */

List_clear(&entries); /* Освобождает память, занятую данными формы. */

return 0; }

Стандартное устройство вывода

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

Даже если вы не используете nph -сценарий, серверу нужно дать одну директиву, которая сообщит ему сведения о вашей выдаче. Обычно это HTTP-заголовок Content-Type , но может быть и заголовок Location . За заголовком должна следовать пустая строка, то есть перевод строки или комбинация CR/LF.

Заголовок Content-Type сообщает серверу, какого типа данные выдает ваша CGI-программа. Если это страница HTML, то строка должна быть Content-Type: text/html. Заголовок Location сообщает серверу другой URL - или другой путь на том же сервере, - куда нужно направить клиента. Заголовок должен иметь следующий вид: Location: http:// www. myserver. com/another/place/.

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

В этом разделе мы будем использовать библиотеки CGI.pm и cgic, в которых есть функции для вывода заголовков как HTTP, так и HTML. Это позволит вам сосредоточиться на выводе собственно содержания. Эти вспомогательные функции использованы в примерах, приведенных ранее в этой главе.

Важные особенности сценариев CGI

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

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

Запоминание состояния

Запоминание состояния является жизненно важным средством предоставления хорошего обслуживания вашим пользователям, а не только служит для борьбы с закоренелыми преступниками, как может показаться. Проблема вызвана тем, что HTTP является так называемым протоколом «без памяти». Это значит, что клиент посылает данные серверу, сервер возвращает данные клиенту, и дальше каждый идет своей дорогой. Сервер не сохраняет о клиенте данных, которые могут понадобиться в последующих операциях. Аналогично, нет уверенности, что клиент сохранит о совершенной операции какие-либо данные, которые можно будет использовать позднее. Это накладывает непосредственное и существенное ограничение на использование World Wide Web.

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

В части клиента с появлением Netscape Navigator появилось выглядящее наспех сделанным решение под названием cookies. Оно состоит в создании нового HTTP-заголовка, который можно пересылать туда-сюда между клиентом и сервером, похожего на заголовки Content-Type и Location. Броузер клиента, получив заголовок cookie, должен сохранить в cookie данные, а также имя домена, в котором действует этот cookie. После этого всякий раз при посещении URL в пределах указанного домена заголовок cookie должен возвращаться серверу для использования в CGI-программах на этом сервере.

Метод cookie используется в основном для хранения идентификатора пользователя. Сведения о посетителе можно сохранить в файле на машине сервера. Уникальный ID этого пользователя можно послать в качестве cookie броузеру пользователя, после чего при каждом посещении сайта пользователем броузер автоматически посылает серверу этот ID. Сервер передает ID программе CGI, которая открывает соответствующий файл и получает доступ ко всем данным о пользователе. Все это происходит незаметным для пользователя образом.

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

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

Помимо задач учета предпочтений пользователя и длительного хранения сведений о нем можно привести более тонкий пример запоминания состояния, который дают популярные поисковые машины. Осуществляя поиск с помощью таких служб, как AltaVista или Yahoo, вы обычно получаете значительно больше результатов, чем можно отобразить в удобном для чтения виде. Эта проблема решается тем, что показывается небольшое количество результатов - обычно 10 или 20 - и дается какое-либо средство перемещения для просмотра следующей группы результатов. Хотя обычному путешественнику по Web такое поведение кажется обычным и ожидаемым, действительная его реализация нетривиальна и требует запоминания состояния.

Когда пользователь впервые делает запрос поисковому механизму, тот собирает все результаты, возможно, ограничиваясь некоторым предустановленным предельным количеством. Фокус состоит в том, чтобы выдавать эти результаты одновременно в небольшом количестве, запомнив при этом, что за пользователь запрашивал эти результаты и какую порцию он ожидает следующей. Оставляя в стороне сложности самого поискового механизма, мы встаем перед проблемой последовательного предоставления пользователю некоторой информации по одной странице. Рассмотрим пример 9-4, в котором показан сценарий CGI, выводящий десять строк файла и предоставляющий ему возможность просмотреть следующие или предыдущие десять строк.

Пример 9-4. Сохранение состояния в сценарии CGI

#!/usr/bin/perl -w

use CGI;

Open(F,"/usr/dict/words") or die("He могу открыть! $!");

#Это файл, который будет выводиться, может быть любым.

$output = new CGI;

sub print_range { # Это главная функция программы, my $start = shift;

# Начальная строка файла, my $count = 0;

# Указатель, my $line = "";

# Текущая строка файла, print $output->header,

$output->start_html("Moй словарь");

# Создает HTML с заголовком "Мой словарь", print "\n";

while (($count < $start) and ($line = )) { $count++; }

# Пропустить все строки перед начальной, while (($count < $start+10) and ($line ? )) { print $line; $count++; }

# Напечатать очередные 10 строк.

my $newnext = $start+10; my $newprev = $start-10;

# Установить начальные строки для URL "Next" и "Previous",

print "

";

unless ($start == 0) { # Включить URL "Previous", если только вы

# уже не в начале.

print qq%Previous%; }

unless (eof) { # Включить URL "Next", если только вы # не в конце файла.

print qq% Next%;

}

print «HTML; HTML

exit(0); }

# Если данных нет, начать сначала,

if (not $output->param) {

&print_range(0); }

# Иначе начать со строки, указанной в данных.

&print_range($output->param("start"));

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

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

Так работают AltaVista и другие поисковые машины. При первом поиске генерируется ID пользователя, который скрыто включается в последующие URL. С этим ID связаны один или несколько файлов, содержащих результаты запроса. В URL включаются еще две величины: текущее положение в файле результатов и направление, в котором вы хотите перемещаться в нем дальше. Эти три значения - все, что нужно для работы мощных систем навигации больших поисковых машин.

Впрочем, не хватает еще кое-чего. Использовавшийся в нашем примере файл /usr/diet/words очень велик. Что если на середине чтения мы его бросим, но захотим вернуться к нему позднее? Если не запомнить URL следующей страницы, никакого способа вернуться назад нет, даже AltaVista это не позволит. Если вы перезагрузите свой компьютер или станете работать с другого, невозможно вернуться к результатам прежнего поиска, не вводя заново запрос. Однако такое долговременное запоминание состояния лежит в основе персонализации вебсайтов, о которой мы говорили выше, и стоит посмотреть, как им можно воспользоваться. Пример 9-5 является модифицированным вариантом примера 9-4.

Пример 9-5. Устойчивое запоминание состояния

#!/usr/bin/perl -w

use CGI;

umask 0;

Open(F,"/usr/dict/words") or die("He могу открыть! $!");

Chdir("users") or die("He могу перейти в каталог $!");

# Это каталог, где будут храниться все данные

# о пользователе.

Soutput = new CGI;

if (not$output->param) {

print $output->header,

$output->start_html("Мой словарь");

print «HTML;


<р>Введите свое имя пользователя:


HTML

exit(0); }

$user = $output->param("username");

## Если файла пользователя нет, создать его и установить

## начальное значение в "0",

if (not -e "$user") {

open (U, ">$user") or die("He могу открыть! $!");

print U "0\n";

close U;

&print_range("0");

## если пользователь существует и в URL не задано

## начальное значение, прочесть последнее значение и начать с него.

} elsif (not $output->param("start")) {

Open(U,"Suser") or die("He могу открыть пользователя! $!");

$start = ; close U;

chomp $starl;

uprint range($start);

## Если пользователь существует и в URL не указано

## начальное значение, записать начальное значение

## в файл пользователя и начать вывод.

} else{

Open(U,">$user") or die("He могу открыть пользователя для записи! $!");

print U $output->param("start"), "\n";

close U;

&print_range($output->param("start 1)); }

sub print_range {

my $start = shift;

my $count = 0;

my $line = " "

print $output->header,

$output->start_html(" Мой словарь ");

print "

\n";

 
while
 (($count < $start) and ($line = )) { $count++; }

 
while
 (($count < $start+10) and ($line = ))

 
print
 $line; $count++;


 
my $newnext
 = $start+10;


 
my $newprev
 = $start-10;


 
print
 "

unless (Sstart == 0)

{

print

qq%

Previous%;

}

unless (eof) { print qq% Next%;

# Заметьте, что имя пользователя "username" добавлено к URL.

# В противном случае CGI забудет, с каким пользователем имел дело.

}

print $output->end_html;

exit(0");

}

Меры безопасности

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

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

#!/usr/bin/perl -w

use CGI;

my $output = new CGI;

my $username = $output»param("username");

print $output->header, $output->start_html("Finger Output"),

"

",
 "finger $username", "
", $output->end_html;

Эта программа обеспечивает действующий CGI-интерфейс к команде finger. Если запустить программу просто как finger.cgi, она выведет список всех текущих пользователей на сервере. Если запустить ее как finger.cgi?username=fred, то она выведет информацию о пользователе «fred» на сервере. Можно даже запустить ее как finger. cgi?userna-me=bob@f oo.com для вывода информации об удаленном пользователе. Однако если запустить ее как finger.cgi?username=fred;[email protected]могут произойти нежелательные вещи. Оператор обратный штрих «"" » в Perl порождает процесс оболочки и выполняет команду, возвращающую результат. В данной программе "finger $username* используется как простой способ выполнить команду finger и получить ее результат. Однако большинство командных процессоров позволяет объединять в одной строке несколько команд. Например, любой процессор, подобный процессору Борна, делает это с помощью символа «; ». Поэтому "finger fred;mail [email protected]запустит сначала команду finger, а затем команду mail [email protected]которая может послать целиком файл паролей сервера нежелательному пользователю.

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

#!/usr/local/bin/perl -w

use CGI;

my $output = new CGI;

my $username = $output->param("username");

$|++;

# Отключить буферизацию с целью направления всех данных клиенту,

print $output->header, $putput->start_html("Finger Output"), "

\n";

 
$pid =
 open(C_OUT, "-|");# Эта идиома Perl порождает дочерний процесс и открывает

 
# канал
 между родительским и дочерним процессами,


 
if ($pid)
 {# Это родительский процесс.

 
print
 ; ft Вывести выходные данные дочернего процесса.

 
print
 "
", $output->end_html;

exit(O); ft Завершить программу. }

elsif (defined $pid) { # Это дочерний процесс.

$|++; # Отключить буферизацию.

ехес("/usr/bin/finger",$username) or die("exec() call failed.");

# Выполняет программу finger с Susername в качестве одного единственного
# аргумента командной строки. } else { die("неудачная попытка fork()"); }

# Проверка ошибок.

Как видите, это не на много более сложная программа. Но если запустить ее как finger.cgi?username=fred;[email protected]то программа finger будет выполняться с аргументом fred;mail [email protected]как одним именем пользователя.

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

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

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

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

Если это ваше первое обращение к CGI-программированию, дальнейшее изучение можно продолжить разными путями. По этому предмету написаны десятки книг, многие из которых не предполагают никакого знакомства с программированием. «CGI Programming on the World Wide Web» издательства O"Reilly and Associates охватывает материал от простых сценариев на разных языках до действительно поразительных трюков и ухищрений. Общедоступная информация имеется также в изобилии в WWW. Неплохо начать с CGI Made Really Easy (Действительно просто о CGI) по адресу http://www.jmarshall.com/easy/cgi/ .

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

С начала эпохи Интернет базы данных взаимодействовали с разработкой World Wide Web. На практике многие рассматривают Web просто как одну гигантскую базу данных мультимедийной информации.

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

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

Одна из причин подключения баз данных к Web регулярно дает о себе знать: значительная часть мировой информации уже находится в базах данных. Базы данных, существовавшие до возникновения Web, называются унаследованными (legacy) базами данных (в противоположность неподключенным к Web базам данных, созданным в недавнее время и которые следует назвать «дурной идеей»). Многие корпорации (и даже частные лица) стоят сейчас перед задачей обеспечения доступа к этим унаследованным базам данных через Web. Если только ваша унаследованная база не MySQL или mSQL, эта тема лежит за пределами данной книги.

Как сказано раньше, только ваше воображение может ограничить возможности связи между базами данных и Web. В настоящее время существуют тысячи уникальных и полезных баз данных, имеющие доступ из Web. Типы баз данных, действующих за пределами этих приложений, весьма различны. Некоторые из них используют CGI-программы в качестве интерфейса с сервером баз данных, таким как MySQL или mSQL. Эти типы представляют для нас наибольший интерес. Другие используют коммерческие приложения для взаимодействия с популярными настольными базами данных, такими как Microsoft Access и Claris FileMaker Pro. А другие просто работают с плоскими текстовыми файлами, являющимися самыми простыми базами данных изо всех возможных.

С помощью этих трех типов баз данных можно разрабатывать полезные веб-сайты любого размера и степени сложности. Одной из наших задач на протяжении нескольких следующих глав будет приложение мощи MySQL mSQL к Web с использованием CGI-программирования.

Обеспечение единообразного потока данных между сервером и прикладной программой, которая запускается из-под сервера. CGI определяет протокол обмена данными между сервером и программой.

  • CGI определяет порядок взаимодействия сервера с прикладной программой, в котором сервер выступает инициирующей стороной;
  • CGI определяет механизм реального обмена данными и управляющими командами в этом взаимодействии, что не определено в HTTP.

Такие понятия, как метод доступа, переменные заголовка, MIME, типы данных, заимствованы из HTTP и делают спецификацию прозрачной для тех, кто знаком с самим протоколом.

При описании различных программ, которые вызываются сервером HTTP и реализованы в стандарте CGI, используют следующую терминологию:

CGI-скрипт - программа, написанная в соответствии со спецификацией Common Gateway Interface. CGI-скрипты могут быть написаны на любом языке программирования (C, C++ (язык программирования) , PASCAL, FORTRAN и т.п.) или командном языке (shell (Операционные Системы) , cshell, командный язык MS-DOS, Perl и т.п.). Скрипт может быть написан даже на языке редактора EMAC в системах Unix.

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

Общий шлюзовый интерфейс CGI

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

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

Веб-серверы

Веб-сервер - это сетевое приложение, обслуживающее HTTP-запросы от клиентов, обычно веб-браузеров. Веб-сервер принимает запросы и возвращает ответы, обычно вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными. Веб-серверы - основа Всемирной паутины. С расширением спектра сетевых сервисов веб-серверы все чаще используются в качестве шлюзов для серверов приложений или сами представляют такие функции (например, Apache Tomcat).

Созданием программного обеспечения веб-серверов занимаются многие разработчики, но наибольшую популярность имеют такие программные продукты, как Apache (Apache Software Foundation), IIS (Microsoft), Google Web Server (GWS, Google Inc.) и nginx.

  • Apache - свободное программное обеспечение, распространяется под совместимой с GPL лицензией. Apache уже многие годы является лидером по распространенности во Всемирной паутине в силу своей надежности, гибкости, масштабируемости и безопасности.
  • IIS (Internet Information Services) - проприетарный набор серверов для нескольких служб Интернета, разработанный Майкрософт и распространяемый с серверными операционными системами семейства Windows. Основным компонентом IIS является веб-сервер, также поддерживаются протоколы FTP, POP3, SMTP, NNTP.
  • Google Web Server (GWS) - разработка компании Google на основе веб-сервера Apache. GWS оптимизирован для выполнения приложений сервиса Google Applications.
  • nginx - это HTTP-сервер, совмещенный с кэширующим прокси-сервером. Разработан И. Сысоевым для компании Рамблер. Осенью 2004 года вышел первый публично доступный релиз, сейчас nginx используется на 9-12% веб-серверов. Браузеры
  • Браузер, веб-обозреватель (web-browser) - клиентское приложение для доступа к веб-серверам по протоколу HTTP и просмотра веб-страниц. Как правило браузеры дополнительно поддерживают и ряд других протоколов (например ftp, file, mms, pop3).

Первые HTTP-клиенты были консольными и работали в текстовом режиме, позволяя читать гипертекст и перемещаться по ссылкам. Сейчас консольные браузеры (такие, как lynx, w3m или links) практически не используются рядовыми посетителями веб-сайтов. Тем не менее такие браузеры весьма полезны для веб-разработчиков, так как позволяют «увидеть» веб-страницу «глазами» поискового робота.

Исторически первым браузером в современном понимании (т.е. с графическим интерфейсом и т.д.) была программа NCSA Mosaic, разработанная Марком Андерисеном и Эриком Бина. Mosaic имел довольно ограниченные возможности, но его открытый исходный код стал основой для многих последующих разработок.

Принцип работы CGI

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

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

Механизмы обмена данными

  • через переменные окружения;
  • через командную строку;
  • через стандартный ввод;
  • через стандартный вывод.

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

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

Общие переменные окружения

  • SERVER_SOFTWARE - определяет имя и версию сервера.
  • SERVER_NAME - определяет доменное имя сервера.
  • GATEWAY_INTERFACE - определяет версию интерфейса.

Запрос-ориентированные окружения

  • SERVER_PROTOCOL - протокол сервера. Вообще говоря, CGI разрабатывалась не только для применения в www с протоколом HTTP, но и для других протоколов также, но широкое применение получила только в www.
  • SERVER_PORT - определяет порт TCP (Transmission Control Protocol) - протокол управления передачей), по которому осуществляется взаимодействие. По умолчанию для работы по HTTP используется 80 порт, но он может быть и переназначен при конфигурировании сервера.
  • REQUEST_METHOD - определяет метод доступа к информационному ресурсу. Это важнейшая переменная в CGI. Разные методы доступа используют различные механизмы передачи данных. Данная переменная может принимать значения GET, POST, HEAD и т. п.
  • PATH_INFO - передает программе путь, часть спецификации URL, в том виде, в котором она указана в клиенте. Реально это означает, что передается путь (адрес скрипта) в виде, указанном в HTML-документе.
  • PATH_TRANSLATED - то же самое, что и PATH_INFO, но только после подстановки сервером определенных в его конфигурации вставок.
  • SCRIPT_NAME - определяет адрес скрипта так, как он указан клиентом.
  • QUERY_STRING - переменная определяет содержание запроса к скрипту.

Идентификация пользователя и его машины

  • REMOTE_HOST - доменный адрес машины, с которой осуществляется запрос.
  • REMOTE_ADDR - IP-адрес запрашивающей машины.
  • AUTH_TYPE - тип идентификации пользователя. Используется в случае если скрипт защищен от несанкционированного использования.
  • REMOTE_USER - используется для идентификации пользователя.
  • REMOTE_IDENT - данная переменная порождается сервером, если он поддерживает идентификацию пользователя по протоколу RFC-931. Рекомендовано использование этой переменной для первоначального использования скрипта.

Переменные, определяющие тип и длину передаваемой информации от клиента к серверу

  • CONTENT_TYPE - определяет MIME-тип данных, передаваемых скрипту. Используя эту переменную можно одним скриптом обрабатывать различные форматы данных.
  • CONTENT_LENGTH - определяет размер данных в байтах, которые передаются скрипту. Данная переменная чрезвычайно важна при обмене данными по методу POST, т. к. нет другого способа определить размер данных, которые надо прочитать со стандартного ввода.

Возможна передача и других переменных окружения. В этом случае перед именем указывается префикс "HTTP_". Отдельный случай представляют переменные, порожденные в заголовке HTML-документа в тагах META. Они передаются в заголовке сообщения и некоторые серверы могут порождать переменные окружения из этих полей заголовка.

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

Командная строка используется только при запросах типа ISIN-DEX . При HTML FORMS или любых других запросах неопределенного типа командная строка не используется. Если сервер определил, что к скрипту обращаются через ISINDEX -документ, то поисковый критерий выделяется из URL и преобразуется в параметры командной строки. При этом знаком разделения параметров является символ "+". Тип запроса определяется по наличию или отсутствию символа "=" в запросе. Если этот символ есть, то запрос не является запросом ISINDEX , если символа нет, то запрос принадлежит к типу ISIN-DEX . Параметры, выделенные из запроса, помещаются в массив параметров командной строки argv. При этом после из выделения происходит преобразование всех шестнадцатеричных символов в их ASCII-коды. Если число параметров превышает ограничения, установленные в командном языке, например в shell, то формирования командной строки не происходит и данные передаются только через QUERY_STRING . Вообще говоря, следует заранее подумать об объеме данных, передаваемом скрипту и выбрать соответствующий метод доступа. Размер переменных окружения тоже ограничен, и если необходимо передавать много данных, то лучше сразу выбрать метод POST, т.е. передачу данных через стандартный ввод.

Формат стандартного ввода

Стандартный ввод используется при передаче данных в скрипт по методу POST. Объем передаваемых данных задается переменной окружения CONTENT_LENGTH , а тип данных - переменной CONTENT_TYPE . Если из HTML-формы надо передать запрос типа: a=b&b=c, то CONTENT_LENGTH =7, CONTENT_TYPE =application/x-www-form-urlencoded, а первым символом в стандартном вводе будет символ "а". Следует всегда помнить, что конец файла сервером в скрипт не передается, а поэтому завершать чтение следует по числу прочитанных символов. Позже мы разберем примеры скриптов и обсудим особенности их реализации в разных операционных системах.

Формат стандартного вывода

Стандартный вывод используется скриптом для возврата данных серверу. При этом вывод состоит из заголовка и собственно данных. Результат работы скрипта может передаваться клиенту без каких-либо преобразований со стороны сервера, если скрипт обеспечивает построение полного HTTP-заголовка, в противном случае сервер заголовок модифицирует в соответствии со спецификацией HTTP. Заголовок сообщения должен отделяться от тела сообщения пустой строкой. Обычно в скриптах указывают только три поля HTTP-заголовка: Content-type , Location , Status .

Content-type

Указывается в том случае, когда скрипт сам генерирует документ "на лету" и возвращает его клиенту. В этом случае реального документа в файловой системе сервера не остается. При использовании такого сорта скриптов следует учитывать, что не все серверы и клиенты отрабатывают так, как представляется разработчику скрипта. Так, при указании Content-type: text/html, некоторые клиенты не реализуют сканирования полученного текста на предмет наличия в нем встроенной графики. Обычно в Content-type указывают текстовые типы text/plain и text/html.

Location

Используется для переадресации. Иногда переадресация помогает преодолеть ограничения сервера или клиента на обработку встроенной графики или серверной предобработки. В этом случае скрипт создает файл на диске и указывает его адрес в Location. Сервер, таким образом, передает реально существующий файл. В последнее время серверы стали буферизовать возвращаемые клиентам данные, что приводит к решению вопросов, связанных с повторным запуском скриптов для встраивания графики и разгрузки компьютера с сервером HTTP.

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

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

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

Важно знать, что CGI - это не язык программирования! Это простой протокол, позволяющий веб-серверу передавать данные через stdin и читать их из stdout . Поэтому, в качестве CGI-обработчика может использоваться любая серверная программа, способная работать со стандартными потоками ввода-вывода.

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

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

Недостатки CGI

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

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

Введение.

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

Теория CGI .

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

С момента когда Вы вызвали (например нажали кнопку формы, к которой привязан вызов CGI-программы) CGI-программу до получения вами результата в окно браузера происходит следующее:

Вэб-клиент (например браузер) создает подключение к серверу, указанному в URL;

Вэб-клиент посылает запрос серверу, запрос этот обычно делается с помощью двух методов GET или POST;

Данные из запроса клиента (например значения полей формы) передаются сервером, используя CGI-интерфейс, CGI-программе, указанной в URL;

CGI-программа обрабатывает данные клиента, полученные от сервера и генерирует на основе этой обработки ответ клиенту, который она передает по все тому же CGI-интерфейсу серверу, а он в свою очередь передает его уже непосредственно клиенту;

Сервер разрывает соединение с клиентом.

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

Переменные окружения – они могут быть установлены сервером при запуске программы;

Стандартный поток ввода (STDIN) – с его помощью сервер может передать данные программе;

Стандартный поток вывода (STDOUT) – программа может писать в него свой вывод, передающийся серверу;

Командная строка – в ней сервер может передать некоторые параметры программе.

Стандартные потоки ввода/вывода весьма удобны и широко используются на UNIX-системах, чего не скажешь о windows, поэтому существует спецификация CGI, разработанная специально для windows-систем так и называемая «Windows CGI». Но, естественно, и стандартные потоки ввода/вывода так же можно использовать в windows CGI программировании. Здесь я не буду затрагивать стандарт «Windows CGI», и на это существует по крайней мере две причины – первая, и самая главная – на данный момент не все http-сервера под windows поддерживают эту спецификацию (в частности мой любимый Apache 1.3.19). Вторую причину вы можете наблюдать набрав в любой поисковой системе строчку «Windows CGI». Отмечу относительно этого интерфейса лишь общие детали – все данные от сервера к клиенту передаются посредством обычного для windows *.ini файла, имя которого передается программе в командной строке. При этом все данные в файле уже заботливо разбиты по секциям сервером и вам лишь остается используя функции «GetPrivateProfile*» извлечь их оттуда. Ответ серверу передается опять же посредством файла, имя которого указано в соответствующей записи ini-файла.

Какие же данные могут быть переданы клиентом CGI-программе? – практически любые. В общем случае программе передаются значения полей формы, которые заполняет клиент, но это также могут быть и какие-либо двоичные данные, например файл с картинкой или музыкой. Данные могут быть переданы на сервер двумя различными методами – это метод GET и метод POST. Когда мы создаем форму для заполнения на нашей страничке мы явно указываем каким из приведенных методов мы хотим отправить введенные пользователем данные, делается это в основном тэге формы примерно так:

get action="/cgi-bin/name_script">

При отправке данных методом GET данные браузером считываются из формы и помещаются следом за URL скрипта, за знаком вопроса, если значимых полей в форме несколько, то они передаются все через значёк «&», имя поля и его значение пишутся в URL через знак «=». Например запрос, сгенерированный браузером из формы при нажатии на кнопку, к которой привязан скрипт «/cgi-bin/test.exe», при учете что первое поле формы называется «your_name», второе – «your_age», может выглядеть так:

GET /cgi-bin/test.exe?your_name=Pupkin&your_age=90 HTTP/1.0

Использование метода GET имеет сразу несколько слабых сторон – первое и самое главное – т.к. данные передаются в URL то он имеет ограничение на количество этих самых передаваемых данных. Вторая слабость опять же вытекает из URL – это конфиденциальность, при такой передаче данные остаются абсолютно открытыми. Итак, хорошо если у нас в форме 2-3 небольших поля… встает вопрос что же делать если данных больше? Ответ – использовать метод POST!

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

POST /cgi-bin/test.exe HTTP/1.0

Accept: text/plain

Accept: text/html

Accept: */*

Content-type: application/x-www-form-urlencoded

Content-length: 36

your_name=Pupkin&your_age=90

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

Помимо самих данных сервером устанавливаются и другие переменные окружения вызываемой программы, приведу некоторые из них:

REQUEST_METHOD

Описывает каким именно методом получены данные

Пример :REQUEST_METHOD=GET

QUERY_STRING

Строка запроса, если использовался метод GET

Пример :QUERY_STRING= your_name=Pupkin&your_age=90&hobby=asm

CONTENT_LENGTH

Длина в байтах тела запроса

Пример:CONTENT_LENGTH=31

CONTENT_TYPE

Тип тела запроса

GATEWAY_INTERFACE

Версия протокола CGI

Пример: GATEWAY _ INTERFACE = CGI /1.1

REMOTE_ADDR

IP-Адрес удаленного хоста, то бишь клиента, нажавшего кнопочку в форме

Пример:REMOTE_ADDR=10.21.23.10

REMOTE_HOST

Имя удаленного хоста, это может быть его доменное имя или например имя компьютера в среде Windows, если таковые получены быть не могут, то поле содержит его IP

Пример :REMOTE_HOST=wasm.ru

SCRIPT_NAME

Имя скрипта, использованное в запросе.

Пример :SCRIPT_NAME=/cgi-bin/gols.pl

SCRIPT_FILENAME

Имя файла скрипта на сервере.

Пример :SCRIPT_FILENAME=c:/page/cgi-bin/gols.pl

SERVER _ SOFTWARE

Программное обеспечение сервера

Пример:Apache/1.3.19 (WIN 32)

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

Практическая часть.

Для практики нам понадобятся как минимум 3 вещи – какой-нибудь http-сервер для Windows, все примеры я пробовал на Apache 1.3.19 для Windows, сервер бесплатный, скачать его можно с http://httpd.apache.org/download.cgi . Да, и сервер нам понадобится не абы – какой, а настроенный для запуска cgi-скриптов! Как это делается для сервера используемого вами смотрите документацию. Вторая вещь, которая нам понадобится это, естественно, ассемблер, так же необходимо, чтобы компилятор поддерживал создание консольных WIN32 приложений, я использую Tasm, но прекрасно подойдут и Fasm и Masm и множество других *asm’ов. Ну и наконец самое главное, что потребуется это желание.

Итак, я допускаю, что сервер был вами благополучно поставлен и настроен, так, что в корневой директории документов сервера лежит файлик index.html, который замечательно показывается в браузере, когда вы набираете адрес http://127.0.0.1 . Так же я учту, что где-то в дебрях папок сервера существует папочка «cgi-bin», в которой разрешен запуск скриптов.

Давайте проверим настройку сервера, а заодно и напишем небольшой скрипт. Скрипт наш будет обычным *.bat файлом. Предвижу вопросы – как? неужели? Да, это обычный командный файл, как уже говорилось выше спецификация CGI не делает различий между типами файлов, главное, чтобы сервер мог его запустить, а он в свою очередь, имел доступ к stdin/stdout и переменным окружения, bat-файл, пусть и не в полной мере, но для примера нас вполне устроит. Создадим файл примерно такого содержания:

@echo off rem Заголовок апроса echo Content-type: text/html echo. rem Тело запроса echo "Привет!
echo "С запросом GET пришли данные: %QUERY_STRING%

Файл назовем test.bat и поместим его в директорию для запуска скриптов, скорее всего это будет директория «cgi-bin». Следующее, что нам нужно будет сделать, это каким либо образом вызвать этот скрипт, в принципе, сделать это можно напрямую набрав в окошке адреса браузера примерно следующее «http://127.0.0.1/cgi-bin/test.bat», но давайте сделаем его вызов с нашей главной странички, заодно проверим работу метода GET. Создадим в корне сервера файл index.html со следующим содержанием:

Введите данные для передачи серверу:
Данные:

Теперь при входе на сервер (http://127.0.0.1 в строке адреса браузера) должна появиться форма, наберите в ней что-нибудь и нажмите кнопку «послать», если все было сделано правильно, Вы увидите в окне браузера ответ нашего bat-скрипта. Теперь давайте посмотрим что же мы там намутили.

Как можно догадаться команда «echo» осуществляет вывод в stdout, первым делом мы передаем серверу заголовок нашего ответа – «echo Content-type: text/html». Это есть стандартный заголовок спецификации CGI, говорящий о том, что передавать мы хотим текст или документ html, существуют и другие заголовки. Очень важный момент – заголовок должен отделяться от тела ответа пустой строкой, что мы и делаем следующей командой «echo.». Дальше передается тело самого ответа – это обычный html-документ, в теле документа я для наглядности отображаю одну из переменных среды, переданной нам сервером – «QUERY_STRING», как уже говорилось при методе GET (а это именно наш случай) в этой переменной передаются все введенные пользователем данные, что мы и можем наблюдать в ответе скрипта. Вы могли заметить «кавычки не к месту» в последних 2-х строках файла, сразу после «echo», стоят они там из-за специфичности bat-файлов, как можно заметить тэги html обрамляются символами «<» и «>», в тоже время эти символы служат перенаправлением ввода/вывода в bat-файлах, а посему мы не можем их здесь свободно использовать.

Рекомендую немного побаловаться с подобными bat-скриптами, это бывает очень полезно, попробуйте посмотреть другие переменные окружения. Немного скажу, отступив от темы, на UNIX-системах языки командных интерпретаторов очень сильно развиты и грань между программированием на языке командного интерпретатора и программированием на «реальном» языке программирования весьма и весьма размыта в некоторых случаях, поэтому на UNIX-системах частенько простенькие скрипты пишутся именно на языках командных интерпретаторов, но windows-интерпретатор cmd.exe или, ранее, command.com явно слабоваты для этих целей.

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

2. Программа должна уметь писать в стандартный поток вывода (stdout), чтобы передать результат своей работы серверу;

3. Из первых двух пунктов следует, то, что для того, чтобы сервер мог передать нашей программе что-либо в stdin, а она могла ему что-либо ответить в stdout CGI-программа должна быть консольным приложением;

Этого вполне достаточно для создания полноценного CGI-приложения.

Начнем с последнего пункта. Для получения доступа к переменным окружения Windows-приложения используется функция API «GetEnvironmentStrings», функция не имеет аргументов и возвращает указатель на массив переменных окружения (ИМЯ=ЗНАЧЕНИЕ) разделенных между собой нулем, массив закрывается двойным нулем, при запуске программы сервером в окружение программы помимо стандартных переменных добавляются специфические CGI-переменные, описанные выше, при запуске программы из командной строки вы их не увидите, естественно.

Для того, что бы писать что-то в stdout или читать из stdin сначала мы должны получить хэндлы этих потоков, делается это с помощью функции API «GetStdHandle», в качестве параметра функции передается одно из следующих значений:

STD_INPUT_HANDLE - для stdin (стандартный ввод);

STD_OUTPUT_HANDLE - для stdout (стандартный вывод);

STD_ERROR_HANDLE - для stderr.

Функция возвратит необходимый нам для операций чтения/записи хэндл. Следующее что нам необходимо делать это писать/читать эти потоки. Делается это обычными операциями чтения/записи файлов, т.е. ReadFile и WriteFile. Тут есть одна тонкость, можно подумать, что для этих целей можно использовать WriteConsole/ReadConsole, да это действительно справедливо для консоли и будет прекрасно работать, результаты, так же как и с WriteFile будут выводиться на консоль, но продолжаться это будет пока мы не запустим нашу программу как скрипт на сервере. Происходит это потому что, когда нашу программу запускает сервер хэндлы, возвращаемые функцией «GetStdHandle» уже не будут хэндлами консоли как таковыми, они будут хэндлами pipe, что необходимо для связи двух приложений.

Вот небольшой пример того, как должна выглядеть CGI-программа на ассемблере, думаю разобраться в ней не составит большого труда:>

386 .model flat,stdcall includelib import32.lib .const PAGE_READWRITE = 4h MEM_COMMIT = 1000h MEM_RESERVE = 2000h STD_INPUT_HANDLE = -10 STD_OUTPUT_HANDLE = -11 .data hStdout dd ? hStdin dd ? hMem dd ? header: db "Content-Type: text/html",13,10,13,10,0 start_html: db "Окружение CGI-программы выглядит \ так:
",13,10,0 for_stdin: db "STDIN программы содержит:
",13,10,0 end_html: db "",13,10,0 nwritten dd ? toscr db 10 dup (32) db " - Тип файла",0 .code _start: xor ebx,ebx call GetStdHandle,STD_OUTPUT_HANDLE mov hStdout,eax call GetStdHandle,STD_INPUT_HANDLE mov hStdin,eax call write_stdout, offset header call write_stdout, offset start_html call VirtualAlloc,ebx,1000,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE mov hMem,eax mov edi,eax call GetEnvironmentStringsA mov esi,eax next_symbol: mov al, or al,al jz end_string mov ,al next_string: cmpsb jmp short next_symbol end_string: mov ,">rb<" add edi,3 cmp byte ptr ,0 jnz next_string inc edi stosb call write_stdout, hMem call write_stdout, offset for_stdin call GetFileSize,,ebx mov edi,hMem call ReadFile,,edi, eax,offset nwritten, ebx add edi, mov byte ptr ,0 call write_stdout, hMem call write_stdout, offset end_html call VirtualFree,hMem call ExitProcess,-1 write_stdout proc bufOffs:dword call lstrlen,bufOffs call WriteFile,,bufOffs,eax,offset nwritten,0 ret write_stdout endp extrn GetEnvironmentStringsA:near extrn GetStdHandle:near extrn ReadFile:near extrn WriteFile:near extrn GetFileSize:near extrn VirtualAlloc:near extrn VirtualFree:near extrn ExitProcess:near extrn lstrlen:near ends end _start

Исполняемый файл строится командами:

tasm32.exe /ml test.asm

tlink32.exe /Tpe /ap /o test.obj

Не забудьте, что программа должна быть консольной.

Архив с программой .

Вызывать эту программу можно используя вышеописанную html-форму, нужно только поменять имя test.bat в форме на test.exe и скопировать его в /cgi-bin/ соответственно, при том можно выставить в методе запроса POST, программа его обрабатывает.

Еще хочу отметить, что можно вызывать программу и по-другому, можно создать в каталоге cgi-bin файл например test.cgi с одной единственной строчкой «#!c:/_путь_/test.exe» и вызывать в запросах его, а сервер в свою очередь будет читать первую его строчку и запускать exe-файл, для этого необходимо, чтобы в настройках http-сервера было прописано расширение *.cgi как расширение для скриптов. При таком подходе сервер запустит нашу программу с командной строкой «test.exe путь_к_test.exe» это имеет несколько плюсов – первое, это то, что человек, запускающий наш скрипт не будет даже догадываться на чем скрипт написан, второе – так-как нам передается имя файла с нашей строчкой мы можем например дописать в этот файл какие-либо настройки для нашего скрипта, что упрощает отладку, кстати именно так работают все интерпретаторы – вы успели заметить, что во всех perl/php/итд программах, присутствует подобная строка – указывающая на сам командный интерпретатор. Так вот сервер при запуске cgi-программы, если расширение программы прописано у него как скрипт в настройках читает первую строку файла, и если она оказывается описанного выше формата, то запускает указанную в строчке программу с именем этого файла ч/з пробел, допустим что в строчке указан интерпретатор перла, он получив такой подарок начинает его выполнение, т.к. комментарий в перле это символ «#», то первую строчку он пропускает и идет дальнейшее выполнение скрипта, в общем штука удобная.

Вот в общем и все о чем я хотел написать, не знаю насколько это все окажется Вам полезным, но скажу что у меня работает сервер интрасети используя скрипты на ассемблере. Каюсь, больших оснований делать это не было, но все же я сделал это сначала просто из эстетических соображений и некоторой не охоты учить перл/php или что-то еще. НО я никоим образом не отговариваю Вас учить перл, а наоборот скажу что сделать это нужно, и даже очень нужно, это я понял позже, но все же считаю, что на сильно загруженных серверах, где скорость выполнения, загрузки и объем памяти занимаемый приложением играет решающую роль cgi-скрипты, написанные на ассемблере займут свое достойное место.

  • 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)

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

Еще на эту тему:

Скачать Driver Sweeper – программа для удаления драйверов из OC Windows Скачать программу для удаления драйверов карты Скачать Driver Sweeper – программа для удаления драйверов из OC Windows Скачать программу для удаления драйверов карты
Выкидывает на рабочий стол Sniper Elite V2 Что делать если лагает sniper elite 3 Выкидывает на рабочий стол Sniper Elite V2 Что делать если лагает sniper elite 3
Поиск похожей фотографии в интернет Поиск похожей фотографии в интернет