Комментарий

Убедитесь, что сценарий может выполняться Web-сервером.

Проверьте владельца и права доступа командой Is -I. Чтобы сценарий мог выполняться сервером, для него должны быть установлены необходимые нрава чтения и исполнения. Сценарий должен быть доступен для чтения и исполнения для всех пользователей (или по крайней мере для того, под чьим именем сервер выполняет сценарии). Используйте команду chmod 0755 имя-сценария, если сценарий принадлежит вам, или chmod 0555 имя-сценария, если он принадлежит анонимному пользователю Web, а вы работаете как этот или привилегированный пользователь. Бит исполнения также должен быть установлен для всех каталогов, входящих в путь.

Проследите, чтобы сценарий идентифицировался Web-сервером как сценарий. Больщинство Web-серверов имеет общий для всей системы каталог cgi-bin, и все файлы данного каталога считаются сценариями. Некоторые серверы идентифицируют сценарий CGI как файл с определенным расщирением - например, .cgi или .рсх. Параметры некоторых серверов разрешают доступ только методом GET, а не методом POST, который, вероятно, используется вашей формой. Обращайтесь к документации по Web-серверу, конфигурационным файлам, Web-мастеру и (если ничего не помогает) в службу технической поддержки.

Если вы работаете в UNIX, проверьте, правильно ли задан путь к исполняемому файлу Perl в строке #. Она должна быть первой в сценарии, перед ней даже не разрешаются пустые строки. Некоторые операционные системы устанавливают смехотворно низкие ограничения на размер этой строки - в таких случаях следует использовать ссылки (допустим, из /home/nchh/perl на /opt/installed/third-party/ software/perl-5.004/bin/perl - взят вымышленный патологический пример).

Если вы работаете в Win32, посмотрите, правильно ли связаны свои сценарии с исполняемым файлом Perl.

Проверьте наличие необходимых прав у сценария

Проверьте пользователя, с правами которого работает сценарий, с помощью простого фрагмента из примера 19.2.

Пример 19.2. webwhoami

#/usr/bin/perl

# webwhoami - show web users id

print Content-Type text/plain\n\n

print Running as , scalar getpwuid($>), \n ,

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

Определите ресурсы, к которым обращается сценарий. Составьте список файлов, сетевых соединений, системных функций и т. д., требующих особых привилегий. Затем убедитесь в их доступности для пользователя, с правами которого работает сценарий. Действуют ли дисковые или сетевые квоты? Обеспечивает ли защита файла доступ к нему? Не пытаетесь ли вы получить зашифрованный пароль с помощью getpwent в системе со скрытыми паролями (обычно скрытые пароли доступны только для привилегированного пользователя)?

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

Не содержит ли сценарий ошибок Perl?

Попытайтесь запустить его в командной строке. Модуль CGI.pm позволяет запускать и отлаживать сценарии в командной строке или из стандартного ввода. В следующем фрагменте "D - вводимый вами признак конца файла:

% perl -wc cgi-script tt Простая компиляция

% perl -w cgi-script tt Параметры из stdin

(offline mode: enter name=value pairs on standard input)

name=joe

number=10

% perl -w cgi-script name=]oe number=10 tt Запустить с входными

tt данными формы

% perl -d cgi-script name=]oe number=10 # To же в отладчике

# Сценарий с методом POST в csh

% (setenv HTTP METH0D POST, perl -w cgi-script name=]oe number=10)

# Сценарий с методом POST в sh

% HTTP METHOD=POST perl -w cgi-script name=joe number=10

Проверьте журнал ошибок сервера. Большинство Web-серверов перенаправляет поток STDERR для процессов CGI в файл. Найдите его (попробуйте/usr/local/ etc/httpd/logs/error log, /usr/local/www/logs/emrjog или спросите у администратора) и посмотрите, есть ли в нем предупреждения или сообщения об ошибках.

Не устарела ли ваша версия Perl? Ответ даст команда perl -v. Если у вас не установлена версия 5.004 или выше, вам или вашему администратору следует подумать об обновлении, поскольку 5.003 и более ранние версии не были защищены от переполнения буфера, из-за чего возникали серьезные проблемы безопасности.

Не используете ли вы старые версии библиотек? Выполните команду grep -г version для библиотечного файла (вероятно, находящегося в /usrib/perl5/, /usr/ local/lib/perl5/, /usr/lib/perl5/site perl или похожем каталоге). Для CGI.pm (а фактически - для любого модуля) версию можно узнать и другим способом:

% perl -MCGI -le print CGI->VERS10N 2.40

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

Используете ли вы флаг -w? С этим флагом Perl начинает жаловаться на неинициализированные переменные, чтение из манипулятора, предназначенного только для записи, и т. д.

Используете ли вы флаг -7? Если Perl жалуется на небезопасные действия, возможно, вы допустили какие-то неверные предположения относительно входных данных и рабочей среды вашего сценария. Обеспечьте чистоту данных, и вы сможете спокойно спать по ночам, а заодно и получите рабочий сценарий (меченые данные и их последствия для программ рассматриваются в рецепте 19.4 и на странице руководства perlsec; в списке FAQ по безопасности CGI описаны конкретные проблемы, которых следует избегать).

Используете ли вы директиву use strict? Она заставляет объявлять переменные перед использованием и ограничивать кавычками строки, чтобы избежать возможной путаницы с подпрограммами, и при этом находит множество ошибок.

Проверяете ли вы возврашаемые значения всех системных функций? Многие люди наивно полагают, что любой вызов open, system, rename или unlink всегда проходит успешно. Они возврашают значение, по которому можно проверить результат их работы, - так проверьте!

Находит ли Perl используемые вами библиотеки? Напишите маленький сценарий, который просто выводит содержимое @INC (список каталогов, в которых ищутся модули и библиотеки). Проверьте права доступа к библиотекам (должно быть разрешено чтение для пользователя, с правами которого работает сценарий). Не пытайтесь копировать модули с одного компьютера на другой - многие из них имеют скомпилированные и автоматически загружаемые компоненты, находящиеся за пределами библиотечного каталога Perl. Установите их с нуля.

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

Соблюдает ли сценарий протокол CGI?

Перед возвращаемым текстом или изображением должен находиться заголовок HTTP. Не забывайте о пустой строке между заголовком и телом сообщения. Кроме того, STDOUT в отличие от STDERR не очищается автоматически. Если ваш сценарий направляет в STDERR предупреждения или ошибки, Web-сервер может увидеть их раньше, чем заголовок HTTP, и на некоторых серверах это приводит к ошибке. Чтобы обеспечить автоматическую очистку STDOUT, вставьте в начало сценария следующую команду (после строки # ):

$1 = 1,

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

Справочная информация

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