Підготовка робочого середовища.

Для роботи з написання та налагодження CGI-скриптів на Perl зручно використовувати
локальний Web-сервер, тобто Web-сервер, встановлений на Вашому комп'ютері. При
це з точки зору браузера робота з таким сервером нічим не буде відрізнятися
від роботи з сервером в Інтернет. В якості локального веб-сервера можна
використовувати практично будь-який веб-сервер з Windows; треба тільки, щоб він
підтримував запуск CGI-скриптів.

З найбільш простих варіантів можна запропонувати PWS (Personal Web Server) з
комплекту Windows9x або IIS (Internet Information Server) з NT. Однак, якщо
Ваш сайт використовує такі речі, як SSI, то краще все-таки встановити Apache для
Windows. У більшості сьогоднішніх хостинг-провайдерів варто Apache Web Server
під UNIX-му, так що така сумісність не завадить. Крім того, Apache
дозволяє використовувати додаткові нестандартні змінні середовища CGI, так
що CGI-скрипти, які "в реальності" будуть працювати на Apache, краще
налагоджувати саме на ньому (хоча це моя думка).

Локальний сервер має "доменне ім'я" localhost і IP-адреса 127.0.0.1.
Відповідно, звернення до нього ведеться через URL виду:

http://localhost/ …

Однак для виконання CGI-скриптів на Perl установка Web-сервера
недостатня, треба встановити ще і сам Perl. Я б порекомендував Perl for Win32
від ActiveState. Після установки Perl його потрібно "прописати" в установках
Web-сервера так, щоб він був Script Handler-го для Perl-скриптів. У різних
Web-серверах це робиться по-різному, прочитайте документацію до свого сервера.
Для PWS і IIS установка Perl – завдання особлива. У більшості веб-серверів для
Windows приналежність CGI-скрипта до певного "типу" (Perl-скрипт, ще
якийсь скрипт …), а відповідно і handler-у визначається з розширення
імені файлу. Якщо на Вашому сервері це так, треба встановити для CGI-скриптів на
Perl таке розширення, яке воно у Вашого хостинг-провайдера (стандартом
де-факто є *. cgi, всречаются та *. pl). У Apache приналежність скрипта
визначається не з розширення, а по рядку "#!…" на початку скрипта, як майже
у всіх UNIX-серверах.

При установці усього вищевикладеного для нас дуже важлива можливість запускати
Perl-скрипти "без веб-сервера", тобто як звичайні програми. Це дуже зручно при
перевірці їх на синтаксичні помилки.

Перевірити правильну установку всього можна, написавши простий скрипт:

#! (Шлях до Перл)
print "Content-Type: text/plain ;
charset=windows-1251

";
print "Скрипт відпрацював успішно, Вітаю!";


Збережіть цей скрипт у файлі, наприклад, test.cgi і покладіть цей файл у вашу
cgi-bin папку.

Тепер перевірте роботу скрипта, запустивши браузер і виконавши URL:

http://localhost/cgi-bin/test.cgi

Якщо все нормально, ви повинні побачити у вікні браузера наступний висновок:

Скрипт відпрацював успішно! Вітаю!

Якщо ж Ви замість цього висновку скрипта побачили на екрані сам скрипт або щось
на кшталт "Access Denied", "Permission Denied", "Forbidden" або нічого не побачили
взагалі (як при завантаженні "порожнього" документа), то перевірте налаштування Вашого
веб-сервера – швидше за все, у Вас невірно встановлені права доступу на Вашу cgi
-Теку.

Тепер спробуємо запустити наш CGI-скрипт як звичайну програму на Perl.
Зайдемо в яку-небудь команднострочную оболонку (наприклад, FAR manager) і
наберемо:

perl (адреса Вашого скрипта)

У результаті Ви повинні побачити висновок:

Content-Type: text/plain ;charset=windows-1251

Скрипт відпрацював успішно! Вітаю!

Замість слів в останньому рядку можлива "абракадабра" – це нічого
страшного; просто невідповідність кодувань в скрипті і в оболонці, в якій ми
його виконуємо. Головне, щоб він запрацював.

Якщо обидва вищезгадані тесту пройшли успішно – вітаю! Тепер Ви можете
налагоджувати більшість CGI-скриптів на своєму комп'ютері, не сплачуючи провайдеру за
це ні копійки! Тепер у Вас є свій маленький "інтернет в мініатюрі":)))

Прийоми налагодження скриптів.


Досить поширеною синтаксичною помилкою є пропуск ";" наприкінці
оператора. (Особливо це характерно для тих хто звик до Бейсік, де
роздільник рядка є роздільником між операторами. У Perl, як і в
C / C + +, всі переклади рядка, повернення каретки і табуляції прирівняні за
значущості до пробілу і називаються "пробільними символами". Роздільниками
операторів вони не є. Єдиним винятком є їх використання в
строкових константах, де вони є "самі собою", але це тільки підтверджує
правило, що вони не поділяють оператори.)

Отже, якщо Ваш скрипт містить синтаксичну помилку, то повідомлення про цю
помилку все одно до браузера не "дійде". Частіше за все при синтаксичну помилку в
скрипті сервер видає помилку "500 Internal Server Error". Що ж, це
дійсно вважається "внутрішньої помилкою сервера" … Ось тільки в якій вона
рядку?!

Але ж ми тепер можемо запустити CGI-скрипт "як програму", і побачити
повідомлення Perl про помилку!

Якщо у вищевказаному скрипті зробити навмисну помилку, прибравши ";" наприкінці
передостаннього рядка, то запустивши його "через сервер", ми швидше за все побачимо
великими літерами написане "500 Internal Server Error" (Внутрішня помилка
сервера). А якщо ми запустимо його "як програму", то побачимо повідомлення на кшталт
наступного:

syntax error at test.cgi line 3, near "print"
Execution of test.pl aborted due to
compilation errors.

У першому рядку вказано, що синтаксична помилка сталася у файлі
test.cgi, у рядку 3, поруч зі словом print. По-моєму, досить вичерпна
інформація! 🙂 (У другому рядку сказано, що виконання скрипта перервано через
помилок компіляції).

Тепер ми шукаємо рядок 3, оператор print і виправляємо помилки. Також досить
неприємною помилкою, що призводить до, на перший погляд, абсолютно незрозумілому
поведінці скрипта, є пропуск закриває фігурної дужки (}). Найчастіше
Perl визначить це як помилку компіляції, але в мене були випадки, коли помилки не
видавалося. Взагалі, всі помилки в CGI-скриптах можна, на мій погляд, умовно
розділити на наступні категорії:


  1. Синтаксичні (помилки компіляції);
  2. Помилки взаємодії з CGI;
  3. Помилки взаємодії з іншими програмами та / або файлами;
  4. Логічні.

Перші помилки найзручніше знаходити описаним вище способом.

До других відноситься некорретний висновок скрипта: скрипт повинен виводити свій
відповідь у форматі HTTP, тобто поля заголовка відповіді, потім – порожній рядок, а потім
– Власне тіло відповіді. В описаному вище прикладі виводилася рядок заголовка:

Content-Type: text/plain ;charset=windows-1251

потім-порожній рядок – і тіло відповіді:

Скрипт відпрацював успішно! Вітаю!

При цьому сервер, отримавши відповідь від скрипта, розбирає виданий їм заголовок,
додає в нього додаткові поля і основну рядок відповіді. Тому
CGI-скрипту зовсім необов'язково формувати повний заголовок. Зазвичай
обов'язковим є зазначення поля Content-Type, але в будь-якому випадку порожня
рядок після заголовка обов'язково повинна бути

Кілька слів про так званих nph-CGI-скриптах. Це скрипти, повністю
формують HTTP-заголовок. Тому сервер не повинен "розбирати" заголовки,
видані такими скриптами, а передавати браузеру все "як є". Звідси й
назва – nph (non-parsed headers – неразбіраемие заголовки). Для деяких
серверів такі скрипти повинні мати певну будову імені файлу (ім'я
повинно починатися з nph-), для інших це не обов'язково.

Також до помилок зв'язку з CGI відноситься неправильне зазначення змінних середовища
CGI, а також – для скриптів, які обробляють форми – методу передачі даних від
форми (GET або POST). При цьому, якщо скрипт очікує даних, посланих методом
POST (на стандартний ввід), а у формі помилково зазначений метод GET, то скрипт
"Застрягне" – він буде чекати надходження даних на стандвртний введення! Якщо ж
скрипт приймає дані за методом GET, а у формі вказаний POST, скрипт відпрацює,
але не отримає з форми ніяких даних (як якщо б у формі не було ні одного
поля).

Для скриптів, які виводять "картинки" (GIF, JPG), характерною помилкою є
ASCII-режим передачі. Відразу після відкриття файлу оператором open цього файлу
відповідає ASCII-режим читання / запису, призначений для "простих текстів"
(Text / plain), як, наприклад, текст у "блокноті".

Всі файли, які задіяні у висновку картинки, (в тому числі STDOUT!)
повинні бути переведені в "бінарний" режим Perl-оператором:

binary FILE;

Інакше відбудеться спотворення даних, оскільки він буде передаватися як текст:
по-перше, відбудеться заміна "кінців рядків", по-друге, символ з кодом 0 буде
сприйнятий як кінець файлу.

До помилок зв'язку із зовнішніми програмами та файлами можна віднести невірний
виклик, наприклад, UNIX-команд sendmail, date і т.п. Сюди ж можна віднести і
неправильний шлях до Perl, записаний у першому рядку після #!.

Як же налагоджувати на локальній машині скрипти, що використовують, скажімо,
sendmail, якщо у Вас (під Windows) немає sendmail? Найбільш простий спосіб –
закоментувати те місце скрипта, яке висилає лист. Воно швидше за все в
загальному випадку має вигляд:

open EMAIL, "| путь_к_sendmail
спісок_получателей ";
print EMAIL "….";
….
close EMAIL;

де в операторі open відкривається sendmail, EMAIL – дескриптор файлу; може
бути будь-хто. Таким чином, можна перевірити роботу скрипта без висилання повідомлення
по E-Mail, якщо воно є допоміжним (скажімо, у гостьових книгах,
висилають вебмайстеру повідомлення про нову запису).

Можна зробити й іншим шляхом: замість відкриття sendmail в команді open
записати відкриття файлу на запис. Нічого іншого при цьому міняти не потрібно.

У цьому випадку при "відсиланні повідомлення" створиться файл з цим листом, і Ви
зможете вручну проконтролювати його формат.

До речі, оскільки E-Mail адреса має вигляд user @ hostname, а символ @ в Perl-
позначення масиву, то "пряма" запис такої адреси викличе помилку! Тому
перед @ потрібно ставити зворотний слеш. Тобто адреса в рядку Perl повинен
мати вигляд user @ hostname. Те ж саме відноситься і до інших зарезервованим
символів, наприклад, $.

Щодо команди date можна сказати, що в більшості випадків її може
замінити функція perl

scalar localtime

яка повертає рядок з поточною датою / часом, наприклад:

Sun Oct 22 16:11:42 2000

Така заміна цілком можлива, якщо отримане значення дати / часу не
розбирається CGI-скриптом, а просто записується в лог-файл (або використовується
"Як є" по-іншому).

Таким чином, в більшості випадків роботу скрипта можна перевірити навіть при
відсутності необхідних йому програм, стандартних для UNIX.

Щодо помилки зв'язку з файлами слід згадати невірно встановлені права
доступу на допоміжні файли, використовувані скриптом.

Остаточна налагодження CGI-скриптів на сервері.


Отже, Ваш скрипт працює на локальному комп'ютері чудово, тепер настав
час перенести його на сервер.

Отже, на що слід звернути увагу:

1. Шлях до Perl в першому рядку.

Змініть його на шлях до Perl Вашого хостингу. Налагоджуючи скрипт, Ви або взагалі
не потребували в цій рядку, або, якщо Ви вели налагодження на Apache, то цей шлях
на Вашому комп'ютері швидше за все інший.

2. Шляхи до інших програм, використовуваним CGI-скриптом.

3. Імена файлів, до яких звертається скрипт.

У Windows немає відмінностей між великими та малими літерами в іменах файлів,
тобто A. TXT і a.txt – ідентичні імена. У UNIX, на базі якого працює
більшість інтернет-серверів, великі і малі літери в іменах файлів –
різні символи. Таким чином, скрипт, що відкриває файл a.txt командою:

open FILE,"a.TXT";

буде нормально працювати під Windows, але не захоче працювати під UNIX (файл
не буде знайдено).

4. Режим закачування файлів на сервер.

Найбільш частою помилкою є закачування всього сайту в "бінарному" режимі.
І якщо з закачаними в такому режимі html і txt – файлами особливих проблем не буде
(Хоча можуть виникнути), закачані таким чином скрипти працювати _не будут_.
Всі файли CGI-скриптів, а також використовуваних ними текстових файлів, повинні бути
закачані в ASCII-режимі.

5. Права доступу до файлів.

Навіть якщо все зроблено правильно, скрипт після закачування на UNIX-сервер навряд чи
відразу почне працювати.

Для того, щоб він почав працювати, треба встановити права доступу для файлів
CGI-скрипта і використовуваних ними файлів.

Як правило, відразу після закачування файлів на сайт їм всім встановлюються
деякий "стандартний" набір прав (за замовчуванням), наприклад:

-rw-r–r–

Загалом, всі файли з точки зору необхідного до них доступу можна розділити
на 3 групи:


  1. Файли CGI-скрипта;
  2. Файли, які використовуються CGI-скриптом для читання;
  3. Файли, які CGI-скрипт використовує для читання і запису;

Як правило, хостинг провайдер, дозволяє використання CGI, вказує,
які права доступу повинні бути встановлені для файлів кожного типу.

Якщо ні, то як компроміс можна використовувати такі установки:

CGI-скрипт –rwx-rxrx (755);
Файли для читання –rw-r – r – (644);
Файли для запису –rw-rw-rw-(666);

УВАГА! На деяких хостингах рекомендуються інші, більш суворі
конфігурації прав доступу, забезпечують більш надійний захист від злому для
Вашого сайту і системи в цілому! Тому дотримуйтесь рекомендацій свого
хостинг-провайдера, якщо вони є!

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*