Стандарт CGI

Коло завдань, що вирішуються Web-сервером, обмежений. В основному він зводиться до підтримки НТТР-взаємодії та доставки клієнту Web-документів. Будь-які " нестандартні" дії реалізуються за допомогою спеціальної програми, яка взаємодіє з веб-сервером і клієнтом. Ця взаємодія підкоряється певним правилам.

Основний набір таких правил - стандарт CGI (Common Gateway Interface - інтерфейс загального шлюзу), який визначає порядок запуску програми на комп'ютерах тере-сервері, способи передачі програмі параметрів і доставки результатів її виполненія клієнту. Програма, написана за правилами CGI, називається CGI-сценарієм (script CGI), хоча це не означає, що на сервері не може виконуватися двійковий файл.

Завдяки цьому інтерфейсу для розробки додатків можна використовувати будь-яку мову програмування, яка має засобами взаємодії зі стандартними пристроями введення / виводу. Такими можливостями мають в також сценарії для вбудованих командних інтерпретаторів операційних систем.

Виконання будь-якої програми (у тому числі CGI-сценарію) можна умовно розділити на п'ять етапів.

1. Запуск програми.

2. Ініціалізація і читання вихідних даних.

3. Обробка даних.

4. Висновок результатів виконання.

5. Завершення програми.

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

Щоразу, коли веб-сервер отримує запит від клієнта, він аналізує вміст запиту і повертає відповідний відповідь:

- якщо запит містить вказівку на файл, що знаходиться на жорсткому диску, то сервер повертає в складі відповіді цей файл;

- якщо запит містить вказівку на програму і необхідні для неї аргументи, то сервер виконує програму і результат її роботи повертає клієнту.

CGI визначає:

- яким чином інформація про сервер і запиті клієнта передається програмі в формі аргументів і змінних оточення;

- яким чином програма може передавати назад додаткову інформацію про результати (наприклад про тип даних) у формі заголовків відповіді сервера.

У переважній більшості випадків запуск CGI-сценарію здійснюється клацанням на кнопці Submit, сформованої за допомогою дескриптора < input тyре = " submit" >, який знаходиться на HTML-сторінці між < form> і < / form>. Не знаючи призначення атрибутів action і method, неможливо зрозуміти, як відбувається виклик програми і передача параметрів.

Значенням атрибута action дескриптора < form> є URL файлу, що містить код CGI-сценарію. Так, наведене нижче вираз означає, що файл з кодом CGI-сценарію знаходиться на сервері www.myhp.edu в каталозі cgi-bin в файлі script.рl.

< form action = " https://www.myhp.edu/cgi-bin/script.pl" method = " post" >

Як веб-сервер розрізняє, що треба зробити з файлом, на який вказує URL, - передати його вміст клієнтові або запустити файл на виконання? Існує два способи розпізнавання файлів, що містять тексти CGI-сценаріїв.

- перший спосіб полягає в тому, що при установці веб-сервера один з каталогів спеціально виділяється для зберігання сценаріїв. Зазвичай такий каталог отримує ім'я cgi-bin (або Scripts для веб-сервера IIS). В цьому випадку, якщо клієнт запитує файл з каталогу cgi-bin, сервер сприймає такий запит як команду на запуск сценарію. Файли з інших каталогів інтерпретуються як HTML-документи;

- другий спосіб використовує розширення файлу. При налаштуванні сервера вказується, що файли з певними розширеннями містять коди сценаріїв.

Ідентифікація по розширенню використовується відносно рідко. Найчастіше всі сценарії поміщаються в / cgi-bin, / Scripts або в інший каталог, спеціально виділений для їх зберігання.

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

Інформація, передана клієнту, повинна відповідати протоколу HTTP, тобто складатися з заголовка і тіла відповіді. Як правило, отримавши дані від сценарію, сервер самостійно додає перший рядок заголовка.

HTTP / 1.0 200 OK

Формування інформаційних полів, що входять до складу заголовка, - завдання сценарію. Щоб дані, передані сценарієм, були правильно інтерпретовані клієнтом, необхідно, щоб в заголовку було присутнє як мінімум поле Content-type. За заголовком повинна слідувати порожній рядок. При відсутності полів заголовка реакція браузера буде непередбачуваною. В подібних випадках браузер зазвичай намагається відобразити отриману інформацію як текстовий файл.

Найприродніший формат для браузера - формат HTML. Результати роботи сценарію зазвичай оформляються у вигляді веб-сторінки, тобто повертаються дані слід доповнити дескрипторами HTML. Таким чином, відповідь CGI-сценарію клієнту зазвичай виглядає так:

Якщо сценарій викликається з форми, йому передаються ті дані, які користувач ввів за допомогою інтерактивних елементів, відображуваних на веб-сторінці - передача інформації CGI-сценарієм здійснюється в два етапи: спочатку браузер передає дані веб-серверу, потім веб-сервер передає їх сценарієм.

У більшості випадків крім кнопки Submit форма містить інші інтерактивні елементи, кожен з яких має ім'я (атрибут NAME) і значення (атрибут VALUE, або послідовність символів, введена користувачем). З імен елементів і їх значень формується рядок параметрів, яка має наступний формат.

ім'я = значення & ім'я = значення &... & ім'я = значення

Кожен параметр являє собою ім'я керуючого елемента та його значення, розділені знаком рівності, а кілька таких пар об'єднують рядок за допомогою символу " & ". Якщо до складу імені або значення входить символ " & " або " =", то подібні символи кодуються послідовність знака відсотка " %", за яким слідують дві шістнадцяткові цифри, що визначають код символу. Так, наприклад, послідовністю " % 21" кодується знак оклику "! ". Як правило, при передачі параметрів трехсімвольнимі послідовностями замінюються все знаки, крім латинських букв, цифр і символу пробілу (останній замінюється знаком " +").

Таким чином, перед використанням рядка параметрів її треба декодувати. Алгоритм декодування надзвичайно простий і включає в себе наступні дії:

- виділити з рядка параметрів пари ім'я = значення.

- виділити з кожної пари ім'я і значення.

- у кожному імені та кожному значенні замінити символи " +" пропусками.

- кожну послідовність з символу " %" і двох шістнадцяткових і перетворити в ASCII-символ.

Атрибут method дескриптора < form> має або значення " GET", або значення " POST". Значення " GET" і " POST" визначають два різних методи передачі параметрів сценарієм:

- якщо атрибут method має значення " GET", рядок параметрів передається разом з URL викликається сценарію. Роздільником між URL і рядком параметрів є символ "? ".

- якщо атрибут method має значення " POST", рядок параметрів передається в тілі HTTP-запиту.

Розглянемо, як повинен вести себе CGI-сценарій, щоб правильно обробити дані в залежності від методу, використаного при передачі даних, рядок параметрів доставляється CGI-сценарієм різними способами.

Якщо атрибут METHOD дескриптора < FORM> мав значення " GET", рядок параметр передається серверу як значення змінної оточення QUERY_STRING.

При використанні методу POST дані доставляються сценарієм по-іншому. Вони передаються через стандартний потік вводу (STDIN). Щоб сценарій зміг визначити, скільки символів слід читати зі стандартного вводу, веб-сервер встановлює значення змінної оточення CONTENT_LENGTH, рівним довжині рядка параметрів.

Отримавши управління, сценарій в першу чергу повинен з'ясувати, за допомогою якого методу виконувалася передача параметрів. Ця інформація міститься в змінній оточення REQUEST_METHOD.

Таким чином, в простому випадку, щоб виконати обробку рядка параметрів, достатньо знати призначення трьох змінних оточення: REQUEST_METHOD, QUERY_STRING і CONTENT_LENGTH.

Приклад сценарію на мові Perl, який повертає клієнту рядок параметрів, наведено нижче. Сценарій визначає, який метод використовувався для передачі даних, читає рядок параметрів і передає її клієнту, попередньо доповнивши HTML-дескрипторами.

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

Сценарії

До основних достоїнств розробки додатків на стороні веб-сервера у формі сценаріїв можна віднести наступні:

- оскільки сценарії не компілюються а інтерпретуються, то помилки в сценарії викличуть тільки діагностичне повідомлення, але не призведуть до дестабілізації веб-сервера або операційної системи;

- кращі виражальні можливості. Мова сценаріїв як правило має власний проблемно-орієнтований набір команд, і один рядок сценарію може робити те ж, що кілька десятків рядків на традиційній мові. Як наслідок, на цій мові може писати програміст низької кваліфікації;

- підтримка багатоплатформеності.

Оскільки сценарії інтерпретуються з вихідного коду динамічно при кожному виконанні, вони виконуються зазвичай значно повільніше готових програм, транслювався в машинний код на етапі компіляції.

У плані швидкодії сценарні мови можна розділити на:

- мови динамічного розбору (наприклад command.com). Інтерпретатор зчитує інструкції з файлу програми мінімально вимагаються блоками, і виконує ці блоки, не читаючи подальший код;

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

В розглянемо коротко найбільш відомі мови розробки сценаріїв для веб-додатків.

Python

Python - високоуровневий мова програмування загального призначення з акцентом на продуктивність і читаність коду. Мова Python поєднує в собі мінімалізм синтаксису ядра і великий обсяг корисних функцій в стандартній бібліотеці.

Python підтримує структурну, об'єктно-орієнтовану, функціональну, імперативну і аспектно-орієнтовану парадигми.

Його основні архітектурні риси:

- динамічна типізація;

- автоматичне керування пам'яттю;

- повна інтроспекція;

- механізм обробки виключень;

- підтримка багатопоточних обчислень;

- зручні високорівневі структури даних.

Код в Python організовується у функції і класи, які можуть об'єднуватися в модулі (які в свою чергу можуть бути об'єднані в пакети).

Для всіх основних платформ Python має підтримку характерних для даної платформи технологій (наприклад, Microsoft COM / DCOM). Cуществует навіть спеціальна версія Python для віртуальної машини Java - Jython, що дозволяє інтерпретатору виконуватися на будь-якій системі, що підтримує Java, при цьому класи Java можуть безпосередньо використовуватися з Пітона і навіть бути написаними на Python. Кілька проектів забезпечують інтеграцію з платформою Microsoft.NET, основні з яких - IronPython і Python.Net.

Стандартна бібліотека Python має кошти для роботи з багатьма мережевими протоколами і форматами інтернету, наприклад, модулі для написання HTTP-серверів і клієнтів, для розбору і створення поштових повідомлень, для роботи з XML і т. П. Набір модулів для роботи з операційною системою дозволяє писати крос-платформні додатки. Існують також модулі для роботи з регулярними виразами, текстовими кодуваннями, мультимедійними форматами, криптографічними протоколами, архівами, серіалізациі даних, підтримка юніт-тестування та ін.

Ruby

Ruby - інтерпретована мова високого рівня для швидкого і зручного об'єктно-орієнтованого програмування. Ruby володіє незалежною від операційної системи реалізацією многопоточности, суворої динамічною типізацією, «складальником сміття» і багатьма іншими можливостями. Багато особливості синтаксису і семантики мови Perl запозичені в Ruby.

Перша загальнодоступна версія Ruby з'явилася в 1995 р

Ruby - повністю об'єктно-орієнтована мова:

- всі дані є об'єктами, на відміну від багатьох інших мов, де існують примітивні типи;

- кожна функція є методом;

- змінні Ruby містять не самі об'єкти, а посилання на них;

- присвоєння - це не передача значення, а копіювання посилання на об'єкт;

- в Ruby можна додавати методи не тільки в будь-які класи, а й в будь-які об'єкти. Наприклад, можна додати до деякої рядку довільний метод.

Масиви в Ruby можуть автоматично змінювати розмір, можуть містити будь-які елементи і мова надає потужні засоби для їх обробки.

Ruby поставляється з великою стандартною бібліотекою. Це, насамперед, бібліотеки для роботи з різними мережевими протоколами на стороні сервера і клієнта, засоби для роботи з різними форматами представлення даних (XML, XSLT, YAML, PDF, RSS, CSV, WSDL). Також є бібліотеки для роботи з архівами, датами, кодуваннями, матрицями, засоби для системного адміністрування, розподілених обчислень, підтримки багатопоточності і т. Д.

У мові Ruby також реалізований простий і зручний механізм для розширення мови за допомогою бібліотек, написаних на Сі, що дозволяє легко розробляти додаткові бібліотеки. Для уніфікованого доступу до баз даних розроблена бібліотека Ruby DBI.

До недоліків інтерпретатора Ruby можна віднести наступні:

- невисока швидкість роботи;

- відсутність підтримки потоків операційної системи (для Unix-подібних операційних систем є підтримка процесів ОС), є в експериментальній версії 1.9;

- відсутність вбудованої підтримки юнікода (можлива робота з використанням додаткових бібліотек, є в експериментальній версії 1.9);

- відсутність компіляції в байткод. (При цьому є можливість компілювати Ruby в Java і.NET байткод, використовуючи компілятор JRuby і Ruby.NET). В експериментальну версію 2.0 входить віртуальна машина YARV, компілює Ruby в байткод і суттєво прискорює виконання.

ASP

ASP (Active Server Pages) - технологія, розроблена компанією Microsoft, що дозволяє легко створювати додатки для Веб.

Програмування на ASP дає розробникам доступ до інтерфейсу програмування додатків Internet Information Server за допомогою мови сценаріїв VBScript і JScript.

ASP працює на платформі операційних систем лінії Windows NT і на веб-сервері Microsoft IIS.

Файли ASP представляють собою сценарії, що інтерпретуються по мірі надходження запитів. ISAPI-розширення ASP.DLL пов'язано в IIS з розширеннями файлів.asp або.asa.

Порядок обробки таких файлів виглядає наступним чином:

- ASP.DLL переглядає файли з зазначеними розширеннями на наявність тегів, що позначають впроваджений код для виконання на сервер і передає знайдений код в Windows Script Host (WSH);

- WSH виконує цей код і повертає результат файлу ASP.DLL;

- ASP.DLL передає IIS цей результат і вміст самого файлу ASP;

- IIS повертає відповідь клієнту, від якого надійшов запит.

Розглянемо основи синтаксису ASP.

IIS розрізняє код, що виконується на сервері, і вміст, що відправляється клієнтові за допомогою ASP.DLL, аналізуючи файл ASP на наявність початкового " < %" і кінцевого " %> " тегів і виконуючи код, розташований між ними, за допомогою WSH.

Розглянемо приклад:

У прикладі перший рядок коду < % Language = VBScript%> повідомляє про необхідність використовувати інтерпретатор мови VBScript. Для вставки рядка в документ був використаний метод Write стандартного об'єкта Response.

Подія веб-запиту в ASP обробляється за допомогою наступних об'єктів:

- Response. Використовується для запису даних в запит HTTP, що повертається клієнту;

- Application. Містить параметри і конфігурації з налаштування роботи ASP для даного веб-сайту;

- Request. Зберігає вміст HTTP-запиту і забезпечує допоміжні функції для обробки даних HTTP-запиту;

- Server. Містить інформацію про веб-сервері, веб-сайті, а також забезпечує підтримку викликає програми;

- Session. Являє собою стан заданого веб-сеансу з заданим хостом клієнтом.

ISAPI

Для веб-сервера IIS (Internet Information Server). був розроблений спеціальний програмний інтерфейс для створення додатків розширюють стандартні можливості веб-сервера.

ISAPI (Internet Server Application Programming Interface) - багатоланковий API для IIS.

ISAPI також реалізований у вигляді модуля mod_isapi для веб-сервера Apache. Таким чином, серверні додатки, розроблені для MS IIS можуть також виконуватися в Apache та інших веб-серверах.

На противагу CGI - ISAPI-додаток завантажується в тому ж адресному просторі, що й веб-сервер IIS. Це дозволяє підвищити продуктивність додатків завдяки скороченню витрат на запуск окремих процесів. Однак збій ISAPI-додатки може привести до нестійкої роботи самого веб-сервера. У 6-ій версії IIS є можливість запуску додатків в рамках окремого процесу.

ISAPI включає в себе 2 компоненти: розширення та фільтри.

Таким чином, усе різноманіття розроблюваних ISAPI-додатків зводиться тільки до цих двох типів. І фільтри і розширення компілюються в DLL файли динамічно запускаються веб-сервером.

ISAPI програми можуть розроблятися за допомогою будь-яких мов, що підтримують експорт стандартних С-функцій, наприклад С, С ++, Delphi Pascal. Для розробки є обмежене число бібліотек для розробки ISAPI додатків, наприклад Intraweb-компоненти Delphi Pascal, спеціальні MFC-класи, спеціальна С ++ бібліотека серверних технологій ATL.

До найбільш важливих особливостей ISAPI-розширень можна віднести наступні:

- ISAPI-розширення мають доступ до всіх функціональних можливостей IIS;

- реалізуються у вигляді DLL-модулів, що завантажуються в просторі процесу, контрольованого IIS;

- клієнти можуть звертатися до ISAPI-розширень також як до статичних HTML сторінкам;

- ISAPI-розширення можуть бути асоційовані з окремими розширеннями файлів, з цілими каталогами або сайтами.

ISAPI-фільтри необхідні для зміни або вдосконалення функціональності IIS. Вони зазвичай працюють з IIS-сервером і фільтрують кожен запит. Фільтри застосовуються для аналізу і модифікації вхідних і вихідних потоків даних.

Фільтри також як і розширення реалізуються у вигляді DLL файлів.

Зазвичай ISAPI-фільтри використовуються для вирішення наступних завдань:

- зміна даних в запиті клієнта (URL або заголовків);

- управління відображенням URL в фізичні файли;

- управління іменами і паролями користувачів при анонімної або базової аутентифікації;

- аналіз та модифікація запитів по завершенні аутентифікації;

- модифікація відповіді веб-сервера;

- ведення журналів та аналіз трафіку;

- реалізація власної аутентифікації;

- управління шифрацией і стисненням.

Варто відзначити, що існують реалізації у вигляді ISAPI-розширень для таких інструментальних засобів як:

- ASP (Active Server Pages);

- ASP.NET;

- ColdFusion;

- Perl ISAPI (Perlis);

- PHP.

Платформа.NET Framework надає можливість розробки та інтеграції веб-додатків. ASP.NET є однією зі складових інфраструктури.NET Framework і фактично є платформою для створення веб-додатків і веб-сервісів, що працюють під управлінням IIS.

ASP.NET зовні багато в чому нагадує більш стару технологію ASP, але в той же час внутрішній устрій ASP.NET істотно відрізняється від ASP. Компанія Майкрософт ASP.NET побудувала на базі CLR (Common Language Runtime), який є основою всіх додатків.NET. Розробники можуть створювати код для ASP.NET, використовуючи мови програмування, що входять до.NET Framework: C #, Visual Basic.NET, JScript.NET та інші.

Розглянемо більш детально, чим відрізняється ASP.NET від ASP.

Класичний ASP має такі недоліки:

- використовуються тільки мови сценаріїв, які дають великий програш в продуктивності (через їх интерпретованість) і не підтримують багато можливості об'єктно-орієнтованого програмування;

- логіка подання (у вигляді коду HTML) не відділена від бізнес-логіки (виконуваного коду), що призводить перемішуванню в одному файлі коду HTML з кодом сценарію;

- неможливо повторно використовувати готові рішення в інших проектах (можливо тільки копіювання коду сценаріїв).

В файлах ASP.NET включається код на таких мовах програмування як C #, JScript.NET, VisualBasic.NET, що дозволяє застосовувати безпосередньо в веб-додатках можливості об'єктно-орієнтованого програмування. Також істотно скорочується обсяг коду, написаного вручну за рахунок застосування серверних об'єктів, автоматично генеруючих код елементів управління HTML. Можливе використання стандартного середовища розробки Visual Studio.NET, тобто ASP.NET має перевагу в швидкості в порівнянні зі сценарними технологіями, так як при першому зверненні код компілюється і поміщається в спеціальний кеш, а згодом тільки виконується, не вимагаючи витрат часу на парсинг, оптимізацію, і т. Д.

Незважаючи на можливість спільної роботи ASP і ASP.NET на одному веб-сервері, вони не можуть використовувати загальний сеанс. Файли ASP.NET обробляються бібліотекою aspnet_isapi.dll (а не asp.dll), яка, в свою чергу, використовує для виконання коду технологію.NET.

Бібліотека базових класів.NET містить простору імен 3 основних груп:

- елементи web-додатків (протоколи, безпека та ін.);

- елементи графічного інтерфейсу (WebForms);

- web-служби.

Як вже зазначалося раніше, ASP.NET використовує можливості стандартної середовища розробки Visual Studio.Net, і зокрема класи бібліотеки FCL (Framework Class Library).

Розробнику веб-додатків на ASP.NET доступні класи, що входять в наступні простору імен:

В свою чергу простір імен System.Web включає в себе простору імен, назви яких знайомі розробникам веб-додатків на ASP:

В основу розробки веб-додатків на ASP.NET покладено модель поділу коду уявлення та коду реалізації, рекомендована Майкрософт при створенні динамічних документів на за допомогою програмних кодів. Це робиться шляхом розміщення програмного коду або в окремий файл, або всередині спеціального тега для сценаріїв. Файл такого роду зазвичай має розширення *.aspx.cs (*.aspx.vb) і має ім'я, що збігається з ім'ям основного ASPX файлу. В принципі такий підхід дозволяє веб-дизайнеру сконцентруватися роботі з кодом розмітки документа з мінімальними змінами програмного коду, в звичайному ASP впроваджуваного безпосередньо в код розмітки.

Взаємодія користувача з веб-додатком, реалізованому на ASP.NET включає в себе такі процеси:

- при запиті сторінки ASPX ініціюється подія Page_Init, яке виробляє початкову ініціалізацію сторінки та її об'єкта;

- далі ініціюється подія Page_Load, яке може бути використано, наприклад для установки початкових значень для елементів управління. При цьому також можна визначити чи була завантажена сторінка вперше або звернення до неї здійснюється повторно в рамках зворотного відсилання у відповідь на події, пов'язані з елементами управління, розміщеними на сторінці; тобто перевірити властивість Page.IsPostBack;

- далі виконується перевірка валідності елементів сторінки з точки зору коректності введених користувачем даних;

- і, нарешті, слід обробка всіх подій, пов'язаних з діями користувача з моменту останньої зворотної посилання.

Для збереження даних веб-сторінки в проміжках між зверненнями до неї в ASP.NET використовуються стану відображення (view state).

Якщо дані, введені в веб-форму, необхідно зробити доступними іншим веб-формам того ж додатка, ці дані необхідно зберегти в об'єктах Application і Session. Об'єкти Application доступні всім користувачам додатки і можуть розглядатися як глобальні змінні, звернення до яких можливо з будь-яких сеансів. Об'єкти Session доступні тільки в рамках одного сеансу, і тому вони виявляються доступними тільки одному користувачеві.