19.1. Написание сценария CGI 671

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

Сценарии CGI вызываются двумя основными способами, которые называются методами, - но не путайте методы HTTP с методами объектов Perl! Метод GET используется для получения документов в ситуациях, когда идентичные запросы должны давать идентичные результаты - например, при поиске в словаре. В методе GET данные формы хранятся внутри URL. Это позволяет сохранить запрос на будущее, но ограничивает общий размер запрашиваемых данных. Метод POST отправляет данные отдельно от запроса. Он не имеет ограничений на размер, но не может сохраняться. Формы, обновляющие информацию на сервере (например, при отправке ответного сообщения или модификации базы данных), должны использовать POST. Клиентские броузеры и промежуточные прокси-серверы могут кэшировать и обновлять результаты запросов GET незаметно для пользователя, но запросы POST не кэшируются. Метод GET надежен лишь для коротких запросов, ограничивающихся чтением информации, тогда как метод POST надежно работает для форм любого размера, а также подходит для обновления и ответов в схемах с обратной связью. По умолчанию модуль CGI использует POST для всех форм.

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

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

Чтобы прочитать входные данные пользовательской формы, передайте функции param имя нужного поля. Если на форме имеется поле с именем «favorite», то вызов param( "favorite") вернет его значение. В некоторых элементах форм (например, в списках) пользователь может выбрать несколько значений. В таких случаях ра ram возвращает список значений, который можно присвоить массиву.

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

use CGI qw(.standard), $who = param( Name"), $phone = param( Number), @picks = param("Choices");

При вызове без аргументов param возвращает список допустимых параметров формы в списковом контексте или количество параметров формы в скалярном контексте.

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

Как видно из решения, модуль CGI упрощает не только ввод, но и вывод данных. Он содержит функции для генерации заголовков HTTP и HTML-кода. Функция header строит текст заголовка. По умолчанию она генерирует заголовки для документов text/html, но вы можете изменить тип содержимого и передать другие необязательные параметры:

print header( -TYPE => text/plain , -EXPIRES => +3d ),

Модуль CGLpm также применяется для генерации HTML-кода. Звучит тривиально, но модуль CGI проявляется во всем блеске при создании динамических форм с сохранением состояния (например, страниц, предназначенных для оформления заказов). В модуле CGI даже имеются функции для генерации форм и таблиц.

При выводе элементов формы символы &, <, > и в выходных данных HTML автоматически заменяются своими эквивалентами. В пользовательских выходных данных этого не происходит. Именно поэтому в решении импортируется и используется функция escapeHTML - даже если пользователь введет специальные символы, это не вызовет ошибок форматирования в HTML.

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

t> Смотри также-

Документация по стандартному модулю CGI; http: www.w3-org/CGI/; рецепт 19.7.

19.2. Перенаправление сообщений об ошибках

Проблема

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

Решение

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

Комментарий

Задача отслеживания сообщений в сценариях CGI пользуется дурной славой. Даже если вам удалось найти на сервере журнал ощибок, вы все равно не сможете определить, когда и от какого сценария поступило то или иное сообщение. Некоторые недружелюбные Web-серверы даже прерывают работу сценария, если он неосторожно выдал в STDERR какие-нибудь данные до генерации заголовка Content-Type - а это означает, что флаг -w может навлечь беду.

На сцене появляется модуль С01::Саф. Он замещает warn и die, а также функции сагр, сгоак и confess обычного модуля Сагр более надежными и содержательными версиями. При этом данные по-прежнему отсылаются в журнал ошибок сервера.

use CGI Carp

warn This IS a complaint , die But this one is serious ,

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

BEGIN {

use CGI Carp qw(carpout),

open(LOG, »/var/local/cgi-logs/mycgi-log )

or die Unable to append to mycgi-log $\n , carpout(*LOG),

Фатальные ошибки могут даже возвращаться клиентскому броузеру - это удобно при отладке, но может смутить рядового пользователя.

use CGI Carp qw(fatalsToBrowser), die Bad error here ,

Даже если ошибка произойдет до вывода заголовка HTTP, модуль попытается избежать ужасной ошибки 500 Server Error. Нормальные предупреждения по-прежнему направляются в журнал ошибок сервера (или туда, куда вы отправили их функцией саг pout) с префиксом из имени приложения и текущего времени.

> Смотри также-

Документация по стандартному модулю С01::Саф; описание BEGIN в рецепте 12.3.

19.3. Исправление ошибки 500 Server Error

Проблема

Сценарий CGI выдает ошибку 500 Server Error.

Решение

Воспользуйтесь приведенным ниже списком рекомендаций. Советы ориентированы на аудиторию UNIX, однако общие принципы относятся ко всем системам.