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

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

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

Почему важно сделать правильный выбор?

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

Поэтому, определяясь с выбором, пройдите по такому чек-листу:

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

По какому критерию определялись сервисы email-рассылок, включенные в этот обзор?

Сервисов для email-рассылок очень много. Только в рейтинге EmailSoldiers участвует порядка 20 платформ. Разумеется, в рамках одной статьи вы не сможете найти полноценный обзор всех инструментов, поэтому мы сосредоточимся только на некоторых из них.

В обзор также не вошли сервисы:

• сильно отстающие от уровня обозреваемых
• специализированные сервисы для доставки только транзакционных или триггерных писем (например, TriggMine , UniOne , Mandrill)
• сервисы, уровня маркетинг + (например, MindBox)

На что обращать внимание при выборе сервиса?

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

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

Третье - учитывайте мнение всех, кто будет работать в команде email-маркетинга.

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

Разные сервисы монетизируются по-разному. Например, MailChimp можно использовать бесплатно на базовых настройках, в нем есть функционал, доступный только для платных аккаунтов, а ещё есть pro-уровень. То же касается Getresponse.

В eSputnik или Unisender абсолютно весь функционал доступен в любом тарифе.

Пятое - обращайте внимание на то, как позиционирует себя сам сервис. Например, сервис для ecommerce проектов с базой от 50 000 контактов. Если вы являетесь целевой аудиторией компании, то, скорее всего, она предлагает специальные решения для вашей ниши.

О субъективизме в сравнении сервисов рассылки

Этот обзор, как и любые другие обзоры - очень субъективен. Как бы вы ни старались объективизировать информацию, всегда столкнетесь с противоречием:

1. Качественный обзор не может написать человек, не имеющий реальной практики работы с сервисом; условно объективные обзоры, основанные на четких критериях, пишут люди, не имеющие опыта работы с сервисами (возможно, даже ни с одним из них).
2. Специалист, имеющий реальный опыт и знающий, что важно, а что нет, физически не может одинаково подробно изучить все сервисы, о которых пишет. Даже если есть такая задача, всё заканчивается первой проблемой, которую удобнее решить другим, более знакомым сервисом. Но это не значит, что ту же задачу невозможно решить в другом сервисе, даже если это будет сложнее.

Важно! В конце статьи будет таблица со сравнением сервисов email-рассылки по нескольким критериям.

До этого я рассмотрю только особые, в основном, уникальные характеристики сервисов.

Идеально подойдет: контентным проектам, малому и среднему бизнесу для решения несложных задач.

Главные особенности.

1. Автоматизация, ориентированная на результат

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

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

Зато теперь можно отслеживать статистику по каждой цепочке и фиксировать, сколько пользователей пришло к «успеху», а сколько - к «провалу».

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

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

В целом, мне не очень нравится сегментация в Unisender. Как и в Mailchimp, она строится на двух понятиях: списки и сегменты внутри списков. При этом, нельзя объединять или комбинировать сегменты из разных списков в один, не прибегая к экспорту-импорту.

Общие впечатления

Очень популярный сервис на СНГ пространстве, с хорошей аналитикой и визуализацией, но с ограниченными возможностями в сегментации и автоматизации.

Идеально подойдет: интернет-магазинам и маркетплейсам.

Главные особенности.

Отчеты eSputnik позволяют очень быстро понять, если с письмом что-то не так. Статистика по доменам покажет, если вы попали в спам, даже без обращения к PostMaster. Такая же есть и в платной версии MailChimp.

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

Дополнительный бонус - интеграция с BigQuery для формирования кастомных отчетов.

2. Гибкая сегментация

Огромное количество условий и всего три типа групп позволяют создавать какие-угодно комбинации. Самая востребованная в ecommerce - сегментация по RFM-матрице. Например, вы можете создать группу «Клиенты с количеством покупок больше 10, со средним чеком $100, совершившие последнюю покупку 30 дней назад».

Сегментация - наверное, самая сильная сторона eSputnik. И идеологи сервиса планируют активно развивать эту сторону, открывая ещё больше возможностей.

3. Гибкая автоматизация

Несмотря на то, что сервис не интегрирован практически ни с одной CRM/CMS платформой, его API позволяет решать любые маркетинговые задачи.

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

4. Решения для интернет-магазинов

За счет того, что сервис сфокусирован на ecommerce, он предлагает готовые решения, необходимые интернет-магазинам: , товарные рекомендации, реактивационные триггерные сообщения, интеграция с базой заказов и многое другое.

5. Редактор писем, которому нет равных

Новый редактор писем (приложение Stripo , если вы хотите воспользоваться им, работая с другим сервисом) - несомненно, одна из сильных сторон продукта.

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

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

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

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

Общие впечатления

В целом сервис демонстрирует функционал, характерный больше для «маркетинг +» уровня, а если говорить о ценовой политике - доступнее многих более слабых платформ.

Идеально подойдет: контентным проектам, малому бизнесу.

Главные особенности.

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

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

2. Интеграция с большим количеством платформ

Поскольку сервис - мировой лидер, большинство компаний интегрируются с ним по своей инициативе. И это удобно. Например, работа в связке MailChimp-SUMO - сплошное удовольствие.

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

4. Отслеживание выполненных целей

Это действительно ценный отчет, которого нет, например, в eSputnik. Функция называется Analytics360 и доступна только для pro-аккаунтов. С ее помощью вы сможете отслеживать конверсии, доход, выполненные цели, считать ROI.

5. Ручная кастомизация всего, что связано с формами подписки

Регулируйте вручную, как будут выглядеть формы и страницы подписки, отписки, обновления данных, попапы и статические формы. Легко устанавливайте сгенерированный код на сайт. То, чего не хватает в eSputnik.

Недостатки

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

Общие впечатления

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

Идеально подойдет: образовательным платформам, инфобизнесу, b2b.

Главные особенности.

1. Инструменты комплексного маркетинга

Я уже упоминала о лендингах, которые можно создавать прямо в MailChimp и использовать их в email-кампаниях. Это не так сложно, если честно, учитывая, что редактор - всё тот же, что и редактор писем. Красивый маркетинговый ход.

Но у Getresponse есть и другие фишки, кроме лендингов, - платформа для проведения вебинаров, сервис для создания опросов.

Отличное сочетание для инфобизнеса и образовательных платформ.

CRM-вкладка - ещё одна находка для тех, кто работает с небольшими базами подписчиков и длинными этапами сделок. Этот функционал окончательно определил аудиторию, на которую ориентируется сервис.

2. Шаблоны автоматизации

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

Если у вас есть регулярно обновляемый блог, с помощью RSS модуля вы сможете настроить отправку дайджеста с заданной регулярностью по заданному шаблону заданной группе получателей. Функционал очень удобный. Аналогичный есть в MailChimp и Unisender.

4. Скоринг и тегирование пользователей

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

Общие впечатления

Интерфейс очень френдли, есть масса обучающих хорошо визуализированных материалов.

Идеально подойдет: малому и среднему бизнесу.

Главные особенности.

Конечно, это не решающее преимущество, но особенность, которой, по крайней мере, нет в других обозреваемых сервисах.

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

Зато можно создавать нестандартные формы подписки на push, например, всплывающие popup-окна.

SMTP (Simple Mail Transfer Protocol) - предоставляемое сервисом решение для отправки транзакционных сообщений. Вы можете интегрировать его со своей системой отправки транзакционных сообщений, при этом, контролировать доставляемость и смотреть статистику отправленных писем в аккаунте SendPulse.

Надежные серверы, выделенные IP адреса, SPF и DKIM записи увеличивают вероятность того, что ваши письма не попадут в спам.

Общие впечатления

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

Сравнительная таблица сервисов email-рассылки

Критерий / Сервис
Редактор писем	Адаптивный	Адаптивный	Адаптивный		Адаптивный, ограниченные возможности
Сегментация	Средний уровень	RFM сегментация, высокий уровень гибкости	Высокий уровень	Средний уровень	Средний уровень
Аналитика	Средний уровень	Высокий уровень	Высокий уровень	Средний уровень	Средний уровень
Интеграция	API, 25+ платформ	API, Zapier	API, 200+ платформ	API, 200+ платформ	API, 25+ платформ
Автоматизация	Есть планировщик рассылок, автоматизация в бета-режиме	Есть редактор сценариев и система учета событий	Есть редактор сценариев, скоринг, тегирование клиентов	Автоматизация, основанная на задачах маркетинга	Есть редактор сценариев
Мультиканальность	Email, SMS	Email, SMS, Push, Viber	Email	Email	Email, SMS, Push, Viber
Техподдержка		Русскоязычная, несколько каналов, ответ в рабочее время — в течение 10 минут	Русскоязычная, email, чат, ответ в течение 30 минут	Англоязычная, несколько каналов, ответ в рабочее время — в течение 2-3 часов	Русскоязычная, несколько каналов, ответ в рабочее время — в течение 10 минут
Ежемесячный тариф при объеме базы в 10 000 контактов	$51	$59	от $65	от $80	от $35

Заключение

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

Агентства или независимые email-маркетологи тоже имеют весьма аргументированную позицию в отношении сервисов. Узнайте - может ли опытный маркетолог решить ваши задачи. Если да, выясните - какой сервис он собирается для этого использовать.

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

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

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

Введение.

В этой статье я хочу рассказать о 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-скрипты, написанные на ассемблере займут свое достойное место.

Обеспечение единообразного потока данных между сервером и прикладной программой, которая запускается из-под сервера. 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-приложения может поставить под угрозу не только работоспособность веб-сервера, но и информационную безопасность. Впрочем, любую сетевую технологию можно считать потенциально небезопасной уже по определению.

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

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

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

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

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

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

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

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

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

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

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