Використання
CGI при створенні інтерактивних інтерфейсів
 4.1 WWW (World Wide Web) і засоби інтерактивної взаємодії  p>
 4.2Спеціфікація CGI 
 4.2.1Переменние оточення 
 4.2.2Стандартний висновок 
4.2.3Стандартний вхідний потік 
 4.2.4Аргументи командного рядка  p>
 4.3Последовательность дій для обробки вхідних даних cgi-модуля для різних методів запиту GET та POST 
4.3.1Для методу GET 
 4.3.2Для методу POST  p>
 4.4Прімери cgi-модулів  p>
  p>
4.1 WWW (World Wide Web) і засоби
інтерактивної взаємодії
 Мета даної глави познайомити користувача з тією частиною WWW-технологій яка пов'язана зі створенням інтерактивних інтерфейсів і передбачається що
користувач знайомий з основами WWW, HTML і С/С + +.  p>
 У загальному випадку, інтерактивний інтерфейс користувача являє собою систему, що забезпечує взаємодію користувача і програми. Для WWW,
інтерактивний інтерфейс можна визначити як послідовність HTML-документів, що реалізують інтерфейс користувача. Можна також умовно
класифікувати принципи побудови інтерфейсу за типом формування HTML-документа:  p>
 статичний
 динамічний
 У першому випадку джерелом інтерфейсу є HTML-документ, створений в будь-якому текстовому або HTML-орієнтованому редакторі. Отже, даний
документ залишається незмінним протягом використання. У другому випадку джерелом інтерфейсу є HTML-документ згенерований cgi-модулем.
Отже, з'являється певна гнучкість у видозміні інтерфейсу під час використання.  p>
 Таким чином, можна ввести поняття інтерактивного інтерфейсу для WWW.  p>
 Інтерактивний інтерфейс для WWW є послідовність статичних або динамічно формованих HTML-документів, що реалізують інтерфейс
користувача.  p>
 Практично будь-яке завдання, що вирішує проблему отримання даних від клієнта, пов'язана з побудовою інтерфейсу. Найбільш цікавим є побудова
інтерфейсів до різних баз даних, доступ до SQL-сервера, отримання інформації від периферійних пристроїв, створення клієнтських робочих місць. Все це
можливо за допомогою CGI (Common Gateway Interface).  p>
 Common Gateway Interface (CGI) є стандартом інтерфейсу зовнішньої прикладної програми з WWW сервером.  p>
 Завдання побудови вищезгаданих інтерфейсів ділиться на дві частини:  p>
 Клієнтська частина
 Серверна частина
 
  p>
 Малюнок 4-1. Дві частини інтерактивного інтерфейсу.  h2>
Клієнтська частина
 Для створення клієнтської частини необхідно створити HTML-документ, в якому реалізований інтерфейс з користувачем. У мові HTML це можливо за допомогою
форм.  p>
 Конструкції мови HTML, які використовуються при реалізації форм, дані в додатку
1 до гол. 4.  p>
Серверна частина
 Серверна частина складається з виконуваного модуля, що вирішує основні завдання обробки даних, що надходять від клієнтської частини, формування відповіді у форматі
HTML, і т.д. Такий модуль називається  cgi-модулем  b>.  p>
Методи HTTP запиту
 Для реалізації взаємодії "клієнт-сервер" важливо, який метод HTTP запиту використовує клієнтська частина при зверненні до WWW сервера. Загалом
випадку, запит - це повідомлення, що посилається клієнтом сервера. Перший рядок HTTP запиту (див. гл.3)
включає в себе метод, який повинен бути застосований до запитуваного ресурсу, ідентифікатор ресурсу (URI-Uniform Resource Identifier), і використовувану версію
HTTP-протоколу. У розглянутому нами випадку, клієнтська частина застосовує методи запиту  POST  b> і  GET.  b> Метод POST використовується для запиту
серверу, щоб той прийняв інформацію, включену в запит, як відноситься до ресурсу, вказаним ідентифікатором ресурсу. Метод GET використовується для
отримання будь-якої інформації, ідентифікованої ідентифікатором ресурсу в HTTP запиті.  p>
 Для WWW-сервера стандарту NCSA прикладні програми або CGI-модулі, які обробляють потік даних від клієнта або (і) формують зворотний потік
даних можуть бути написані на таких мовах програмування як:  p>
 C/C + +;
 Будь-який UNIX shell;
 Fortran;
 Perl;
 Visual Basic;
 TCL;
 AppleScript;
4.2 Специфікація CGI
 CGI визначає 4 інформаційних потоку.  p>
 Змінні оточення
 Стандартний вхідний потік
 Стандартний вихідний потік
 Командний рядок
 
  p >
 Малюнок 4-2. CGI-інтерфейс.  h2>
4.2.1 Змінні оточення
 Змінні оточення умовно поділяються на два типи:  p>
 загальні для всіх типів запитів (встановлюються для всіх типів)
 залежать від методу запиту
 До змінних першого типу відносяться наступні змінні:  p>
  SERVER_SOFTWARE  b> містить інформацію про WWW сервер (назва/версія)  p>
  SERVER_NAME  b> містить інформацію про ім'я машини, на якій запущений WWW сервер, символічне ім'я або IP адреса відповідні URL.  p>
  GATEWAY_INERFACE  b> містить інформацію про версію CGI (CGI/версія)  p>
 Наступні змінні є специфічними для різних типів запитів і значення цим змінним присвоюються перед викликом cgi-модуля.  p>
  CONTENT_LENGTH  b> значення цієї змінної відповідає довжині стандартного вхідного потоку в символах.  p>
  CONTENT_TYPE  b> ця змінна специфікована для запитів містять додаткову інформацію, таких як HTTP POST і PUT, і містить тип даних
цієї інформації.  p>
  SERVER_PROTOCOL  b> ця змінна містить інформацію про ім'я і версії інформаційного протоколу (протокол/версія).  p>
  SERVER_PORT  b> значення змінної містить номер порту, на який був посланий запит.  p>
  REQUEST_METHOD  b> метод запиту, що був використаний "POST", "GET", "HEAD" і т.д.  p>
  PATH_INFO  b> значення змінної містить отриманий від клієнта віртуальний шлях до cgi-модуля  p>
  PATH_TRANSLATED  b> значення змінної містить фізичний шлях до cgi-модуля, перетворений зі значення PATH_INFO.  p>
  SCRIPT_NAME  b> віртуальний шлях до виконуваного модуля, який використовується для отримання URL.  p>
  QUERY_STRING  b> значення цієї змінної відповідає рядку символів наступної за знаком "?" в URL відповідного даному запиту. Ця
інформація не декодується сервером.  p>
  REMOTE_HOST  b> містить символічне ім'я віддаленої машини, з якої був зроблений запит. У разі відсутності даної інформації сервер привласнює
пусте значення і встановлює змінну REMOTE_ADDRESS.  p>
  REMOTE_ADDRESS  b> містить IP адреса клієнта  p>
  AUTH_TYPE  b> якщо WWW-сервер підтримує аутентифікацію (підтвердження автентичності) користувачів і cgi-модуль є захищеним від стороннього
доступу те, значення змінної специфікує метод аутотентіфікаціі.  p>
  REMOTE_USER  b> містить ім'я користувача у випадку аутотентіфікаціі.  p>
  REMOTE_IDENT  b> містить ім'я користувача, отримане від сервера (якщо сервер підтримує аутентифікацію згідно RFC 931)  p>
  HTTP_ACCEPT  b> список типів MIME відомих клієнтові. Кожен тип у списку повинен бути відокремлений комою згідно специфікації HTTP (тип/підтип, тип/підтип і
т.д.)  p>
  HTTP_USER_AGENT  b> назва програми перегляду яку використовує клієнт при посилці запиту.  p>
4.2.2 Стандартний вивід
  СGI  b> - модуль виводить інформацію у стандартний вихідний потік. Цей висновок може являти собою або документ, згенерований cgi-модулем, або
інструкцію серверу, де отримати необхідний документ. Зазвичай  cgi  b>-модуль робить свій висновок. Перевага такого підходу в тому, що  cgi  b>-модуль
не повинен формувати повний HTTP заголовок на кожен запит.  p>
  Заголовок вихідного потоку  b> 
 У деяких випадках необхідно уникати обробки сервером виведення cgi-модуля, і
надсилати клієнту дані без змін. Для відмінності таких cgi-модулів, CGI вимагає, щоб їх імена починалися на nph-. У цьому випадку формування
синтаксично правильної відповіді клієнту cgi-модуль бере на себе.  p>
  Заголовки з синтаксичним розбором  b> 
 Висновок cgi-модуля повинен починатися із заголовка містить певні рядка
і завершуватися двома символами CR (0x10).  p>
 Будь-які рядки не є директивами сервера, посилаються безпосередньо клієнтові. На даний момент, CGI специфікація визначає три директиви сервера:  p>
  Content-type  b> 
 MIME або тип повертається документа  p>
 Наприклад:  Content-type  b>: text/html   повідомляє серверу, що наступні за цим повідомленням дані - є документ у форматі HTML
 p>
  Location  b> 
 вказує серверу, що повертається не сам документ, а посилання на нього  p>
 Якщо аргументом є URL, то сервер передасть клієнтові вказівку на перенаправлення запиту. Якщо аргумент є віртуальний шлях,
сервер поверне клієнтові заданий цим шляхом документ, як якби клієнт запитував цей документ безпосередньо.  p>
 Наприклад:  Location:  b> http://host/file.txt призведе до того, що WWW сервер видасть file.txt, як якби він був затребуваний клієнтом. Якщо cgi-модуль
повертає посилання на gopher сервер, наприклад на gopher:// gopher.ncsa.uiuc.edu /. Висновок буде наступний:  p>
  Location  b>: gopher:// gopher.ncsa.uiuc.edu/ p>
  * Status  b> 
 задає серверу HTTP/1.0 рядок-статус, яка буде послана клієнтові у форматі:
nnn xxxxx  p>
 де: nnn - 3-х цифровий код статусу  p>
 ххххх - рядок причини  p>
 Наприклад:  HTTP/1.0 200 OK  b>  p>
 Server: NCSA/1.0a6  p>
 Content-type: text/plain  p>
 <динамічно створюваний текст повідомлення>  p>
 У даному випадку, клієнтові буде повідомлено про успішне виконання запиту.  p>
4.2.3 Стандартний вхідний потік
 У випадку методу запиту  POST  b> дані передаються як вміст HTTP запиту. І будуть надіслані в стандартний вхідний потік.  p>
 Дані передаються cgi-модуля в наступній формі:  p>
 name = value & name1 = value1 &...& nameN = valueN 
 де name - ім'я змінної, 
value - значення змінної, 
 N - кількість змінних  p>
 На файловий дескриптор стандартного потоку введення посилається CONTENT_LENGTH байт. Так само сервер передає cgi-модуля CONTENT_TYPE (тип даних). Сервер не
посилає символ кінця файлу після передачі CONTENT_LENGTH байт даних або після того, як cgi-модуль їх прочитає. Змінні оточення CONTENT_LENGTH і
CONTENT_TYPE встановлюються в той момент, коли сервер виконує cgi-модуль. Таким чином, якщо в результаті виконання форми з аргументом тега FORM --
METHOD = "POST" сформований рядок даних firm = МММ & price = 100023, то сервер встановить значення CONTENT_LENGTH рівним 21 і CONTENT_TYPE в
application/x-www-form-urlencoded, а у стандартний потік введення посилається блок даних.  p>
 У випадку методу  GET  b>, рядок даних передається як частина URL. 
 Тобто наприклад 
http://host/cgi-bin/script?name1=value1&name2=value2  p>
 У цьому випадку змінна оточення QUERY_STRING приймає значення 
 name1 = value1 & name2 = value2  p>
4.2.4 Аргументи командного рядка
  СGI  b>-модуль у командному рядку від сервера отримує:  p>
 залишок URL після імені cgi-модуля як перший параметр
     (перший параметр буде порожній, якщо було присутнє тільки ім'я cgi-модуля), і
     
 список ключових слів як залишок командного рядка для
     скрипта пошуку, або
 чергуються імена полів форми з доданим знаком рівності та
     відповідних значень змінних.
 Ключові слова, імена та значення полів форми передаються декодувати (з HTTP URL формату кодування) і перекодованими відповідно до правил
кодування Bourne shell так, що cgi-модуль у командному рядку отримає інформацію без необхідності здійснювати додаткові перетворення.  p>
4.3 Послідовність дій для
обробки вхідних даних cgi-модуля для різних методів запиту GET та POST
 Виходячи з різниці методів запитів GET і POST, можна визначити послідовність дій для обробки вхідних даних cgi-модуля для різних
типів запитів.  p>
4.3.1 Для методу GET
 Отримати значення змінної QUERY_STRING
 Декодувати імена та їх значення (враховуючи, що всі пробіли при
     декодуванні сервером були замінені символом "+" і всі символи
     з десятковим кодом більше 128 перетворені у символ "%" і
     наступним за ним шістнадцятковим кодом символу.)
 Сформувати структуру відповідності "ім'я - значення" для
     подальшого використання в cgi-модуль
4.3.2 Для методу POST
 Отримати зі стандартного вхідного потоку CONTENT_LENGTH символів
 Декодувати імена та їх значення (враховуючи, що всі пробіли при
     декодуванні сервером були замінені символом " +  b>" і все
     символи з десятковим кодом більше 128 перетворені у символ "%  b>"
     і наступним за ним шістнадцятковим кодом символу.)
 Сформувати структуру відповідності "ім'я - значення" для
     подальшого використання в cgi-модуль
 Очевидно, що відмінність тільки в джерелі даних. Тому, в принципі, можливе створення єдиного модуля для методів POST і GET. Необхідно тільки
додати почало перевірку значення змінної REQUEST_METHOD для визначення методу запиту. Після формування структури "ім'я-значення" можна
приступити до вирішення завдань, заради яких, власне, створювався cgi-модуль. Зрозуміло, що завдання, які вирішуються cgi-модулем, можуть бути дуже різноманітними
(отримання і обробка пошти, доступ до баз даних, гостьова книга і т.д.).  p>
 Наступним важливим моментом є динамічне формування cgi-модулем HTML-документа (оформлення результату роботи модуля). Наприклад, таблиці вибірки
з бази даних.  p>
 Для цього cgi-модуль повинен видати в стандартний вихідний потік заголовок складається з рядка: 
 Content-type: text/html  b> і порожнього рядка (двох символів  CR  b>)  p>
 Після цього заголовка можна давати будь-який текст у форматі HTML.  p>
4.4 Приклади cgi-модулів
 Як приклад розглянемо роботу тестових програм поставляються разом з програмним забезпеченням сервера НТТРD стандарту NCSA.  p>
 Для тестування роботи форм поставляються програми: 
  post-query  b> - для тестування роботи форм з методом запиту POST 
 query  b> - для тестування роботи форм з методом запиту GET 
  util.c -  b> опис функцій для обробки вхідного потоку (використовується
query і post-query).  p>
 Розглянемо простий приклад форми на мові HTML використовує програму query.  p>
  
 
 
  Приклад використання CGI  TITLE> 
 HEAD>