CGI -
Common Gateway Interface є стандартом інтерфейсу
(зв'язку) зовнішньої прикладної програми з інформаційним сервером типу HTTP,
Web сервер.
Звичайно гіпертекстові документи, що
витягаються з WWW серверів, містять статичні дані. За допомогою CGI можна
створювати CGI-програми, названі шлюзами, що у взаємодії з такими
прикладними системами, як система керування базою даних, електронна таблиця,
ділова графіка й ін., зможуть видати на екран користувача динамічну інформацію.
Програма-шлюз запускається WWW сервером
у реальному масштабі часу. WWW сервер забезпечує передачу запиту користувача
шлюзу, а вона у свою чергу, використовуючи засоби прикладної системи, повертає
результат обробки запиту на екран користувача. Програма-шлюз може бути
закодована на мовах C/C++, Fortran, Perl, TCL, Unix Schell, Visual Basic, Apple
Script. Як здійсненний модуль, вона записується в піддиректорій з ім'ям cgi-bin
WWW сервера.
Оригінал опису CGI інтерфейсу -
інструмента зв'язку програма-шлюз з WWW сервером знаходиться у вузлі wist.ifmo.ru .
Для передачі даних про інформаційний запит від сервера до шлюзу, сервер використовує командний рядок і змінні оточення. Ці змінні оточення встановлюються в той момент, коли сервер виконує програму шлюзу.
Інформація шлюзам передається в наступній формі:
ім'я=значення&ім'я1=значення1&..,
де ім'я- ім'я змінної (з оператора FORM, наприклад), і значення - її реальне значення. В залежності від методу, що використовується для запиту, цей рядок з'являється або як частина URL (у випадку методу GET), чи як вміст HTTP запиту (метод POST). В останньому випадку, ця інформація буде послана шлюзу в стандартний потік вводу.
На файловий дескриптор стандартного потоку вводу посилається CONTENT_LENGTH байт. Так само сервер передає шлюзу CONTENT_TYPE (тип переданих даних). Сервер не зобов'язаний посилати символ кінця файлу після відсилання CONTENT_LENGTH байт даних і після того, як шлюз їхній прочитає.
Приклад
Візьмемо результат роботи форми з методом POST
(METHOD="POST") як приклад. Нехай отримано 7 байт, закодованих
приблизно так:
a=b&b=c.
У цьому випадку, сервер встановить значення CONTENT_LENGTH рівний 7 і CONTENT_TYPE у application/x-www-form-urlencoded. Першим символом у стандартному потоці вводу для шлюзу буде "a", за яким буде випливати залишок закодованого рядка.
Шлюз у командному рядку від сервера одержує:
залишок URL після імені шлюзу як перший параметр (перший параметр буде порожній, якщо було присутнє тільки ім'я шлюзу), і
список ключових слів як залишок командного рядка для скрипту пошуку, чи
імена полів, що чергуються, форми з доданим знаком рівності (на парних позиціях) і відповідних значень перемінних (на непарних позиціях).
Ключові слова, імена полів форми і значення передаються розкодованими (з HTTP URL формату кодування) і перекодованими відповідно до правил кодування Bourne shell, так що шлюз у командному рядку одержить інформацію в тому вигляді, як вона є, без необхідності здійснювати додаткові перетворення.
Запити оператора FORM
Запити оператора FORM обробляються таким чином, що кожен параметр, відповідальний за ім'я поля, закінчується знаком рівності, а залишок являє собою значення цього параметра. Якщо є присутнім що не будь або після імені скрипту (шлюзу), то ця інформація передається як перший параметр. Інакше перший параметр буде порожній.
Приклади:
/htbin/foo/x/y/z?name1=value1&name2=value2
викликається як:
/.../foo /x/y/z name1= value1 name2= value2
а
/htbin/foo?name1=value1&name2=value2
викликається як:
/.../foo '' name1= value1 name2= value2
Наступні змінні оточення не є специфічними по типі запитів і встановлюються для всіх запитів.
SERVER_SOFTWARE
Назва і версія інформаційного сервера, що відповідає на запит (і запускає шлюз). Формат: ім'я/версія
SERVER_NAME
Ім'я хосту, на якому запущений сервер, DNS ім'я, чи IP адреса в тім виді, у якому він представлений у URL.
GATEWAY_INTERFACE
Версія CGI специфікації на той момент, коли компілювався сервер. Формат: CGI/версія
Наступні змінні оточення є специфічними для різних запитів, і заповнюються перед викликом шлюзу:
SERVER_PROTOCOL
Ім'я і версія інформаційного протоколу, у якому прийшов запит. Формат: протокол/версія
SERVER_PORT
Номер порту, на який був посланий запит
REQUEST_METHOD
Метод, що був використаний для запиту. Для HTTP, це "GET","HEAD","POST",і т.д.
PATH_INFO
Додаткова інформація про шлях, що передав клієнт. Іншими словами, доступ до шлюзу може бути здійснений по віртуальному шляху, за яким випливає деяка додаткова інформація. Ця інформація передається в PATH_INFO.
PATH_TRANSLATED
Сервер передає перетворену версію PATH_INFO, що містить у собі шлях, перетворений з віртуального у фізичний.
SCRIPT_NAME
Віртуальний шлях до шлюзу, що повинний виконуватися, використовуваний для одержання URL.
QUERY_STRING
Інформація, що випливає за ? у URL, до якого відноситься даний шлюз. Це інформація являє собою рядок запиту. Вона не повинна бути декодована ніяким чином. Поза залежністю від командного рядка ця змінна завжди повинна бути встановлена при наявності такої інформації, .
REMOTE_HOST
Ім'я хосту, що робить запит. Якщо сервер не має такої інформації, він повинний встановити REMOTE_ADDR, а це поле залишити не встановленим.
REMOTE_ADDR
IP адреса хоста, що робить запит.
AUTH_TYPE
Якщо сервер підтримує ідентифікацію користувача, і шлюз є захищеним від стороннього доступу, цей специфічний для протоколу метод ідентифікації використовується для перевірки користувача.
REMOTE_USER
Використовується в ситуаціях, аналогічних попередньому випадку, для збереження імені користувача.
REMOTE_IDENT
Якщо HTTP сервер підтримує ідентифікацію користувача згідно RFC 931, то ця змінна буде містити ім'я користувача, отримане від сервера.
CONTENT_TYPE
Для запитів, що містять додаткову додаткову інформацію, такі як HTTP POST і PUT, тут міститься тип даних цієї інформації.
CONTENT_LENGTH
Довжина даних, що передає клієнт.
На додаток до цього, якщо запит містить додаткові поле заголовка запиту, вони помістяться в змінному оточення з префіксом HTTP_, за яким випливає ім'я заголовка. Будь-які символи '-' у заголовку міняються на символи підкреслення '_'. Сервер може виключити будь-які заголовки, що він вже обробив, такі як Authorization, Content-type, і Content- length. Якщо необхідно, сервер може виключити будь-які (чи взагалі усі) додаткові поля заголовка у випадку, коли їхнє включення може привести до перевищення межі розміру змінного оточення. Прикладом такої перемінної може служити змінна HTTP_ACCEPT, що була визначена в специфікації CGI/1.0. Іншим прикладом може служити заголовок User-Agent.
HTTP_ACCEPT
Список MIME типів, що клієнт може обробити, як задано в HTTP заголовках. Інші протоколи повинні одержати цю інформацію з інших місць (якщо вона їм необхідна). Кожен тип у цьому списку повинний бути відділений коми згідно HTTP специфікації. Формат: тип/підтип, тип/підтип
HTTP_USER_AGENT
Переглядач, що використовує клієнт для попосилання запиту. Загальний формат: програма/версія бібліотека/версія.
Шлюз здійснює свій вивід у стандартний потік виводу. Цей вивід може являти собою чи документ, згенерований шлюзом, чи інструкції серверу, де одержати необхідний документ.
Як правило, шлюз робить свій вивід, що інтерпретується і посилається назад клієнту. Перевага цього підходу полягає в тому, що шлюз не повинний посилати повний HTTP/1.0 заголовок на кожен запит.
Для деяких шлюзів може бути необхідно уникати обробки сервером їхнього виводу, і спілкуватися з клієнтом безпосередньо. Для того, щоб відрізнити такі шлюзи від інших, CGI вимагає, щоб їхні імена починалися з префікса nph-. У цьому випадку, на шлюзі лежить відповідальність за повернення клієнту синтаксично правильної відповіді.
Заголовки із синтаксичним розбором
Вивід шлюзу починається з маленького заголовка. Він містить текстові рядки, у тім же форматі, як і в HTTP заголовку і завершується порожнім рядком (утримуючи тільки символ перекладу рядка чи CR/LF).
Будь-які рядки заголовка, що не є директивами сервера, посилаються безпосередньо клієнту. В даний момент, CGI специфікація визначає три директиви сервера:
Content-type
MIME тип документа, що повертається.
Location
Це поле використовується у випадку, коли необхідно вказати серверу, що повертається не сам документ, а посилання на нього.
Якщо аргументом є URL, то сервер передасть клієнту вказівка на перенапрямлення запиту. Якщо аргумент являє собою віртуальний шлях, сервер поверне клієнту заданий цим шляхом документ, як якби клієнт запитував його безпосередньо.
Status
Ця директива використовується для завдання серверу HTTP/1.0 рядок-статус, що буде послана клієнту. Формат: nnn xxxxx, де nnn - 3-х цифровий статус-код, і xxxxx рядок причини, така, як "Forbidden" (Заборонено).
Приклади
Припустимо, мається деякий текстовий конвертер у HTML. Коли він закінчує свою роботу, він повинний зробити наступний вивід у стандартний вихідний потік:
-- початок виводу --
Content-type: text/html
--- кінець виводу ---
Тепер розглянемо шлюз, що, у деяких випадках, повинний видати документ /path/doc.txt з даного сервера, як якби він був безпосередньо затребуваний клієнтом через http://server:port/path/doc.txt. У це випадку вивід шлюзу буде такий:
-- початок виводу --
Location: /path/doc.txt
--- кінець виводу ---
Нарешті, припустимо, що шлюз повертає посилання на gopher сервер, наприклад на gopher://gopher.ncsa.uiuc.edu/. Вивід шлюзу буде наступний:
-- початок виводу --
Location: gopher://gopher.ncsa.uiuc.edu/
--- кінець виводу ---
Non-parsed headers
Допустимо тепер, що в нас є шлюз, що спілкується з клієнтом безпосередньо. Як уже відзначалося, його ім'я повинне починатися з префікса nph- і він повинний повертати припустимий HTTP заголовок. У цьому випадку, якщо доступ до шлюзу був здійснений зі значенням SERVER_PROTOCOL рівним HTTP/1.0, його вивід повинний задовольняти HTTP/1.0:
-- початок виводу --
HTTP/1.0 200 OK
Server: NCSA/1.0a6
Content-type: text/plain
--- кінець виводу ---
HyperText Transfer Protocol (HTTP) - це протокол високого рівня (а саме, рівня додатків), що забезпечує необхідну швидкість передачі даних, що вимагається для розподілених інформаційних систем гіпермедіа. HTTP використовується проектом World Wide Web з 1990 року.
Практичні інформаційні системи вимагають більшого, ніж примітивний пошук, модифікація й анотація даних. HTTP/1.0 надає відкрита безліч методів, що можуть бути використані для вказівки цілей запиту. Вони побудовані на дисципліні посилань, де для вказівки ресурсу, до якого повинний бути застосований даний метод, використовується Універсальний Ідентифікатор Ресурсів (Universal Resource Identifier - URI), у вигляді місцезнаходження (URL) чи імені (URN). Формат повідомлень подібний з форматом Internet Mail чи Multipurpose Internet Mail Extensions (MIME-Багатоцільове Розширення Пошти Internet).
HTTP/1.0 використовується також для комунікацій між різними користувальницькими переглядачами і шлюзами, що дають гіпермедіа доступ до існуючих Internet протоколам, таким як SMTP, NNTP, FTP, Gopher і WAIS. HTTP/1.0 розроблений, щоб дозволяти таким шлюзам через proxy сервери, без якої-небудь утрати передавати дані за допомогою згаданих протоколів більш ранніх версій.
HTTP ґрунтується на парадигмі запитів/відповідей. Запитуюча програма (звичайно вона називається клієнт) установлює зв'язок з обслуговуючої програмою-одержувачем (звичайно називається сервер) і надсилає запит серверу в наступній формі: метод запиту, URI, версія протоколу, за якої випливає MIME-подібне повідомлення, що містить керуючу інформацію запиту, інформацію про клієнта і, може бути, тіло повідомлення. Сервер відповідає повідомленням, що містить рядок статусу (включаючи версію протоколу і код статусу – успіх чи помилка), за якого випливає MIME-подібне повідомлення, що включає в себе інформацію про сервер, метаінформацію про зміст відповіді, і, імовірно, саме тіло відповіді. Слід зазначити, що одна програма може бути одночасно і клієнтом і сервером. Використання цих термінів у даному тексті відноситься тільки до ролі, виконуваною програмою протягом даного конкретного сеансу зв'язку, а не до загальних функцій програми.
У Internet комунікації звичайно ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням - TCP 80, але також можуть бути використані й іншого номера портів - це не виключає можливості використовувати HTTP як протокол верхнього рівня.
Для більшості додатків сеанс зв'язку відкривається клієнтом для кожного запиту і закривається сервером після закінчення відповіді на запит. Проте, це не є особливістю протоколу. І клієнт, і сервер повинні мати можливість закривати сеанс зв'язку, наприклад, у результаті якої-небудь дії користувача. У будь-якому випадку, розривши зв'язку, ініційований будь-якою стороною, перериває поточний запит, незалежно від його статусу.
Запит - це повідомлення, що посилається клієнтом серверу.
Перший рядок цього повідомлення містить
у собі метод, що повинний бути застосований до запитуваного ресурсу,
ідентифікатор ресурсу і використовувану версію протоколу. Для сумісності з
протоколом HTTP/0.9, існує два формати HTTP запиту:
Запит = Простий-Запит | Повний-Запит
Простий-Запит = "GET" SP Запитуваний-URI CRLF
Повний-Запит = Рядок-Статус
*(Загальний-Заголовок | Заголовок-Запиту | Заголовок-Змісту)
CRLF
[ Зміст-Запиту ]
Якщо HTTP/1.0 сервер одержує Простий-Запит, він повинний відповідати Простий-Відповіддю HTTP/0.9. HTTP/1.0 клієнт, здатний обробляти Повна-Відповідь, ніколи не повинен посилати Простий-Запит.
Рядок Статус починається з рядка з назвою методу, за яким випливає URI-запиту і версія протоколу, що використовується. Рядок Статус закінчується символами CRLF. Елементи рядка розділяються пробілами (SP). У Рядку Статус не допускаються символи LF і CR, за винятком послідовності, що укладає, CRLF.
Рядок-Статус = Метод SP URI-Запиту SP Версія-HTTP CRLF
Слід зазначити, що відмінність Рядка Статус Повного-Запиту від Рядка Статус Простого-Запиту полягає в присутності поля Версія-HTTP.
У поле Метод указується метод, що повинний бути застосований до ресурсу, ідентифікованому URI-запиту. Назви методів чуттєві до регістра. Існуючий список методів може бути розширений.
Метод = "GET"|"HEAD"|"PUT"|"POST"|"DELETE"|"LINK"|"UNLINK"
|додатковий-метод
Список методів, що допускаються окремим ресурсом, може бути зазначений у поле Заголовок-Змісту "Балів". Проте, клієнт завжди оповіщається сервером через код статусу відповіді, чи допускається застосування даного методу для зазначеного ресурсу, тому що допустимість застосування різних методів може динамічно змінюватися. Якщо даний метод відомий серверу, але не допускається для зазначеного ресурсу, сервер повинний повернути код статусу "405 Method Not Allowed", і код статусу "501 Not Implemented", якщо метод не відомий чи не підтримується даним сервером. Загальні методи HTTP/1.0 описуються нижче.
Метод GET служить для одержання будь-якої інформації, ідентифікованої URI-запиту. Якщо URI- Запиту посилається на процес, що видає дані, як відповідь будуть виступати дані, згенеровані даним процесом, а не код самого процесу (якщо тільки це не є вихідними даними процесу).
Метод GET змінюється на "умовний GET", якщо повідомлення запиту містить у собі поле заголовка "If-Modified-Since". У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, зазначеної в заголовку "If-Modified-Since". Алгоритм визначення цього містить у собі наступні випадки:
Якщо код статусу відповіді на запит буде відрізнятися від "200 OK", чи дата, зазначена в полі заголовка "If-Modified-Since" некоректна, відповідь буде ідентичний відповіді на звичайний запит GET.
Якщо після зазначеної дати ресурс змінювався, відповідь буде також ідентичний відповіді на звичайний запит GET.
Якщо ресурс не змінювався після зазначеної дати, сервер поверне код статусу "304 Not Modified".
Використання методу умовний GET спрямовано на розвантаження мережі, тому що він дозволяє не передавати по мережі надлишкову інформацію.
Метод HEAD аналогічний методу GET, за винятком того, що у відповіді сервер не повертає Тіло-Відповіді. Метаінформація, що міститься в HTTP заголовках відповіді на запит HEAD, повинна бути ідентична інформації HTTP заголовків відповіді на запит GET. Даний метод може використовуватися для одержання метаінформації про ресурс без передачі по мережі самого ресурсу. Метод "Умовний HEAD", аналогічний умовному GET, не визначений.
Метод POST використовується для запиту сервера, щоб той прийняв інформацію, включену в запит, як субординантну для ресурсу, зазначеного в Рядку Статус у поле URI-запиту. Метод POST був розроблений, щоб була можливість використовувати один загальний метод для наступних функцій:
Анотація існуючих ресурсів
Додавання повідомлень у групи новин, поштові списки чи подібні групи статей
Доставка блоків даних процесам, що обробляють дані
Розширення баз даних через операцію додавання
Реальна функція, виконувана методом POST, визначається сервером і звичайно залежить від URI- Запиту. Інформація, що додається, розглядається як субординатна зазначеному URI у тім же змісті, як файл субординатний каталогу, у якому він знаходиться, нова стаття субординатна групі новин, у яку вона додається, запис субординатний базі даних.
Клієнт може запропонувати URI для ідентифікації нового ресурсу, включивши в запит заголовок "URI". Проте, сервер повинний розглядати цей URI тільки як рада і може зберегти тіло запиту під іншим URI чи взагалі без нього.
Якщо в результаті обробки запиту POST був створений новий ресурс, відповідь повинна мати код статусу, рівний "201 Created", і містити URI нового ресурсу.
Метод PUT запитує сервер про збереження Тіла-Запиту під URI, рівним URI-запиту. Якщо URI-запиту посилається на вже існуючий ресурс, Тіла-Запиту повинне розглядатися як модифікована версія даного ресурсу. Якщо ресурс, на який посилається URI-запиту не існує, і даний URI може розглядатися як опис для нового ресурсу, сервер може створити ресурс із даним URI. Якщо був створений новий ресурс, сервер повинний інформувати запит клієнта, що направив, через відповідь з кодом статусу "201 Created". Якщо існуючий ресурс був модифікований, повинний бути послана відповідь "200 OK", для інформування клієнта про успішне завершення операції. Якщо ресурс із зазначеним URI не може бути створений чи модифікований, повинне бути послане відповідне повідомлення про помилку.
Фундаментальне розходження між методами POST і PUT полягає в різному значенні поля URI-запиту. Для методу POST даний URI вказує ресурс, що буде керувати інформацією, що міститься в тілі запиту, як деяким придатком. Ресурс може бути обробним дані процесом, шлюзом у який-небудь інший протокол, чи окремим ресурсом, що допускає анотації. На противагу цьому, URI для запиту PUT ідентифікує інформацію, що міститься в Змісту-Запиту. Запит, що використовує, PUT точно знає який URI він збирається використовувати, і одержувач запиту не повинний намагатися застосувати цей запит до якого-небудь іншого ресурсу.
Метод DELETE використовується для видалення ресурсів, ідентифікованих за допомогою URI-запиту. Результати роботи даного методу на сервері можуть бути змінені за допомогою людського втручання (чи яким-небудь іншим способом). У принципі, клієнт ніколи не може бути упевнений, що операція видалення була виконана, навіть якщо код статусу, переданий сервером, інформує про успішне виконання дії. Проте, сервер не повинний інформувати про успіх доти, поки на момент відповіді він не буде збиратися стерти даний чи ресурс перемістити його в деяку недосяжну область.
Метод LINK установлює взаємозв'язку між існуючим ресурсом, зазначеним у URI-запиту, і іншими існуючими ресурсами. Відмінність методу LINK від інших методів, що допускають установлення посилань між документами, полягає в тому, що метод LINK не дозволяє передавати в запиті Тіла-Запиту, і в тому, що в результаті роботи даного методу не створюються нові ресурси.
Метод UNLINK видаляє одну чи більше посилальних взаємозв'язків для ресурсу, зазначеного в URI- Запиту. Ці взаємозв'язки можуть бути встановлені за допомогою методу LINK чи якого-небудь іншого методу, що підтримує заголовок "Link". Видалення посилання на ресурс не означає, що ресурс припиняє чи існування стає недоступним для майбутніх посилань.
Поля Заголовка-Запиту дозволяють клієнту передавати серверу додаткову інформацію про запит і про самого клієнта.
Заголовка-Запиту = Accept | Accept-Charset | Accept-Encoding |
Accept-Language | Authorization | From | If-Modified-Since |
Pragma | Referer | User-Agent | extension-header
Крім того через механізм розширення можуть бути визначені додаткові заголовки; додатка, що їхній не розпізнають, повинні трактувати ці заголовки, як Заголовок-Зміст.
Нижче будуть розглянуті деякі поля заголовка запиту.
У випадку присутності поля From, він повинен містити повний E-mail адресу користувача, що керує програмою-агентом, що здійснює запити. Ця адреса повинна бути задана у форматі, визначеному в RFC 822. Формат даного поля наступний: From = "From" ":" специфікація адреси. Наприклад:
From: webmaster@WWW.org
Дане поле може бути використане для функцій заходу в систему, а також для ідентифікації джерела некоректних чи небажаних запитів. Воно не повинен використовуватися, як несекретна форма розмежування прав доступу. Інтерпретація цього поля полягає в тому, що оброблюваний запит виробляється від імені даного користувача, що приймає відповідальність за застосовуваний метод. Зокрема, агенти-роботи повинні використовувати цей заголовок для того, щоб можна було зв'язатися з тією людиною, що відповідає за роботу робота, у випадку виникнення проблем. Поштовий Internet адреса, що вказується в цьому полі, не зобов'язаний відповідати адресі того хоста, з якого був посланий даний запит. По можливості, адресу повинний бути доступним Internet адресою поза залежністю від того, чи є він у дійсності Internet E-mail чи адресою Internet E-mail представленням адреси інших поштових систем.
Зауваження: Клієнт не повинний використовувати поле заголовка From без дозволу користувача, тому що це може ввійти в конфлікт із його приватними інтересами або з місцевої, використовуваної ним, системою безпеки. Настійно рекомендується надання користувачу можливості заборонити, чи дозволити модифікувати це поле в будь-який момент перед запитом.
Поле заголовка If-Modified-Since використовується з методом GET для того, щоб зробити його умовним: якщо запитуваний ресурс не змінювався в часі, зазначеного в цьому полі, копія цього ресурсу не буде повернута сервером; замість цього, буде повернута відповідь "304 Not Modified" без Тіла-Відповіді.
If-Modified-Since = "If-Modified-Since" ":" HTTP-дата
Приклад використання заголовка:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Метою цієї особливості є надання можливості ефективного відновлення інформації локальних кешів з мінімумом переданої інформації. Той же результат може бути досягнуть застосуванням методу HEAD з наступним використанням GET, якщо сервер указав, що вміст документа змінився.
Поле заголовка User-Agent містить інформацію про користувальницького агента, що послав запит. Дане поле використовується для статистики, простежування помилок протоколу, і автоматичного розпізнавання користувальницьких агентів. Хоча це не обов'язково, користувальницькі агенти повинні завжди включати це поле у свої запити. Поле може містити кілька рядків, що представляють собою назву програмного продукту, необов'язкову косу рису з указівкою версії продукту, а також інші програмні продукти, що складають важливу частину користувальницького агента. За згодою, продукти вказуються в списку в порядку убування їхньої значимості для ідентифікації додатка.
User-Agent = "User-Agent" ":" 1*( продукт )
продукт = рядок ["/" версії-продукту]
версії-продукту = рядок
Приклад:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Рядок, що описує назву продукту, повинний бути коротким і подавати інформацію власне кажучи - використання даного заголовка для рекламування який-небудь інший, що не відноситься до справи, інформації не допускається і розглядається, що як не відповідає протоколу. Хоча в поле версії продукту може бути присутнім будь-який рядок, даний рядок повинний використовуватися тільки для вказівки версії продукту. Поле User-Agent може містити в собі додаткову інформацію в коментарях, що не є частиною його значення.
Після одержання й інтерпретації запиту, сервер посилає відповідь у відповідності з наступною формою:
Відповідь = Проста-Відповідь | Повна-Відповідь
Проста-Відповідь = [ Зміст-Відповіді ]
Повна-Відповідь = Рядок-Статус
*( Загальний-заголовок | Заголовок-Відповіді | Заголовок-Зміст)
CRLF[ Зміст-Відповіді ]
Проста-Відповідь повинна посилатися тільки у відповідь на HTTP/0.9 Простій-Запит, чи в тому випадку, якщо сервер підтримує тільки обмежений HTTP/0.9 протокол. Якщо клієнт посилає HTTP/1.0 Повний-Запит і одержує відповідь, що не починається з Рядка-Статус, він повинний припускати, що відповідь сервера являє собою Просту-Відповідь, і обробляти його відповідно до цього. Варто помітити, що Проста-Відповідь складається тільки з запитуваної інформації (без заголовків) і потік даних припиняється в той момент, коли сервер закриває сеанс зв'язку.
Перший рядок Повного-Запиту є Рядок-Статус, що складається з версії протоколу, за якого випливає цифровий код статусу й асоційоване з ним текстова пропозиція. Всі елементи Рядок-Статус розділені пробілами. Не дозволені символи CR і LF, за винятком завершальної послідовності CRLF.
Рядок-Статус=Версія-HTTP SP Статус-Код SP Фраза-Пояснення.
Тому що Рядок-Статус завжди починається з версії протоколу "HTTP/" 1*ЦИФРА "." 1*ЦИФРА (наприклад HTTP/1.0), існування цього вираження розглядається як основне для визначення того, чи є відповідь Простою-Відповіддю чи Повною-Відповіддю. Хоча формат Проста-Відповідь не виключає появи подібного рядка (що привело б до неправильної інтерпретації повідомлення відповіді і прийняттю його за Повну-Відповідь), імовірність такої появи близька до нуля.
Елемент Статус-Код являє собою 3-х цифровий цілий код, що ідентифікує результат спроби інтерпретації і задоволення запиту. Фраза-Пояснення, що випливає за ним, призначена для короткого текстового опису Статус-Коду. Статус-Код націлений на те, щоб його використовувала машина, а Фраза-Пояснення призначена для людини. Клієнт не зобов'язаний досліджувати і виводити на екран Фразу-Пояснення.
Перша цифра Статус-Коду призначена для визначення класу відповіді. Останні дві цифри не виконують ніякі категоруючі ролі. Існує 5 значень для першої цифри:
1xx: Інформаційний - Не використовується, але зарезервований для використання в майбутньому
2хх: Успіх - Запит був цілком отриманий, зрозумілий, і прийнятий до обробки.
3xx: Перенапрямок - Клієнту варто почати подальші дії для успішного виконання запиту. Необхідна додаткова дія іноді може бути виконано клієнтом без взаємодії з користувачем, але настійно рекомендується, щоб це мало місце тільки в тих випадках, коли метод, що використовується в запиті байдужний (GET чи HEAD).
4xx: Помилка клієнта - Запит, що містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису тих випадків, коли помилка була допущена з боку клієнта. Якщо клієнт ще не завершив запит, коли він одержав відповідь зі Статус-Кодом-4xx, він повинний негайно припинити передачу даних серверу. Даний тип Статус-Кодів застосуємо для будь-яких методів, що вживаються в запиті.
5xx: Помилка Сервера - Сервер не зміг дати відповідь на коректно поставлений запит. У цих випадках
сервер або знає, що він припустився помилки, або не здатний обробити запит. За винятком відповідей на запити HEAD, сервер посилає опис помилкової ситуації і те, чи є цей стан тимчасовим чи постійним, у Змісті-Відповіді. Даний тип Статус-Кодів застосуємо для будь-яких методів, що вживаються в запиті.
Окремі значення Статус-Кодів і відповідні їм Фраза-Пояснення приведені нижче. Дані Фрази-Пояснення тільки рекомендуються - вони можуть бути заміщені будь-якими іншими фразами, що зберігають зміст і допускаються протокол.
Статус-Код = "200" ; OK |
"201" ; Created |
"202" ; Accepted |
"203" ; Provisional Information |
"204" ; No Content |
"300" ; Multiple Choices |
"301" ; Moved Permanently |
"302" ; Moved Temporarily |
"303" ; Method |
"304" ; Not Modified |
"400" ; Bad Request |
"401" ; Unauthorized |
"402" ; Payment Required |
"403" ; Forbidden |
"404" ; Not Found |
"405" ; Method Not Allowed |
"406" ; None Acceptable |
"407" ; Proxy Authentication Required |
"408" ; Request Timeout |
"409" ; Conflict |
"410" ; Gone |
"500" ; Internal Server Error |
"501" ; Not Implemented |
"502" ; Bad Gateway |
"503" ; Service Unavailable |
"504" ; Gateway Timeout |
Код-Розширення
Код-розширення = 3 ЦИФРА
Фраза-Пояснення = рядок *( SP рядок )
Від HTTP додатків не потрібно розуміння всіх Статус-Кодів, хоча таке розуміння, мабуть, бажано. Проте, від додатків потрібно здатність розпізнавання класів Статус-Кодів (ідентифікованих першою цифрою) і відношення до всіх Статус-Кодів статусу відповіді, як якби вони були еквівалентні Статус-Коду x00.
Поля заголовка відповіді дозволяють серверу передати додаткову інформацію про відповідь, що не може бути внесена в Рядок-Статус. Ці поля заголовків не призначені для передачі інформації про зміст відповіді, переданого у відповідь на запит, але там може бути інформація власне про сервер.
Заголовок-Відповіді = Public | Retry-After | Server | WWW-Authenticate | extension-header
Хоча додаткові поля заголовка відповіді можуть бути реалізовані через механізм розширення, додатка, що не розпізнають ці поля, повинні обробляти їхній як поля Зміст-Утримування-заголовок-зміст. Повний опис цих полів можна одержати в специфікації протоколу HTTP у CERN.
Що таке URL?
У World Wide Web для завдання місця розташування файлів на інших серверах мережі Internet використовується URL - Uniform Resource Locator.
URL містить у собі :
метод доступу до ресурсу, тобто протокол доступу (http, gopher, WAIS, ftp, file, telnet і ін.)
мережна адреса ресурсу (ім'я хост-машини і домена)
повний шлях до файлу на сервері
У загальному вигляді формат URL виглядає так:
method://host.domain[:port]/path/filename
де method має одне зі значень, перерахованих нижче
|
File |
|
файл на вашій локальній системі, |
|
Http |
|
файл на World Wide Web сервері |
|
Gopher |
|
файл на Gopher сервері |
|
WAIS |
|
файл на WAIS (Wide Area Information Server) сервері |
|
News |
|
група новин телеконференції Usenet |
|
Telnet |
|
вихід на ресурси мережі Telnet |
Параметр host.domain - адреса ресурсу в мережі Internet.
Параметр port - число, яких необхідно вказувати, якщо метод вимагає номер порту (окремі сервера можуть мати свій відмітний номер порту). Стандартними портами є :
21 - FTP
23 - Telnet
70 - Gopher
80 - HTTP
Тут посилання на більш подробну інформацію про URL англійською мовою.
Повний-Запит і Повна-Відповідь може використовуватися для передачі деякої інформації в окремих запитах і відповідях. Цією інформацією є Зміст-Запиту чи Зміст-Відповіді відповідно, а також Зміст-Заголовка.
Поля Зміст-Заголовка містять необов'язкову метаінформацію про Зміст-Запиту чи Змісту-Відповіді відповідно. Якщо тіло відповідного повідомлення ( запиту чи відповіді) не є присутнім, то Зміст-Заголовка містить інформацію про запитуваний ресурс.
Зміст-Заголовка = Allow |
Content-Encoding | Content-Language | Content-Length |
Content-Transfer-Encoding | Content-Type |Derived-From |
Expires | Last-Modified |Link |
Location | Title | URI-header | Version |Заголовок-Розширення
Заголовок-Розширення = HTTP-заголовок
Деякі з полів заголовка змісту описані нижче.
Поле заголовка Allow являє собою список методів, що підтримує ресурс, ідентифікований URI-запиту. Призначення цього поля - точне інформування одержувача про припустимі методи, асоційованих з ресурсом; це поле повинне бути присутнім у відповіді зі статус кодом "405 Method Not Allowed".
Allow = "Allow" ":" 1#метод
Приклад використання:
Allow: GET, HEAD, PUT
Звичайно, клієнт може спробувати використовувати інші методи. Однак, рекомендується слідувати тим методам, що зазначені в даному полі. У цього поля немає значення за замовчуванням; якщо воно залишено невизначеним, безліч дозволених методів визначається сервером у момент кожного запиту.
Поле Content-Length вказує розмір тіла повідомлення, посланого сервером у відповідь на запит, чи у випадку запиту HEAD, розмір тіла повідомлення, що було б послане у відповідь на запит GET.
Content-Length = "Content-Length" ":" 1*ЦИФРА
Наприклад:
Content-Length: 3495
Хоча це не обов'язково, але все-таки додаткам настійно рекомендується використовувати це поле для аналізу розмірів переданого повідомлення, незалежно від типу інформації, що міститься в ньому. Для поля Content-Length припустимим є будь-яке цілочисельне значення більше нуля.
Поле заголовка Content-Type ідентифікує тип інформації в тілі повідомлення, що посилається стороні, що одержує, чи, у випадку методу HEAD, тип інформації (середовища), що був би посланий, якщо використовувався метод GET.
Content-Type = "Content-Type" ":" типу-середовища
Типи середовищ визначені окремо.
Приклад:
Content-Type: text/html; charset=ISO-8859-4
Поле Content-Type не має значення за замовчуванням.
Поле заголовка містить дату і час, у яке, на думку сторони, що відправляє, ресурс був останній раз модифікований. Семантика даного поля визначена в термінах, що описують, як одержувач повинний його інтерпретувати: якщо одержувач має копію ресурсу, що старше, ніж передана в поле Last-Modified дата, то копія повинна вважатися застарілою.
Last-Modified = "Last-Modified" ":" HTTP-дата
Приклад використання:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Точне значення цього поля заголовка залежить від реалізації сторони, що відправляє, і суті самого ресурсу. Для файлів, це може бути просто його час останньої модифікації. Для шлюзів до баз даних, це може бути час останнього відновлення даних у базі. У будь-якому випадку, одержувач повинний турбуватися лише про результат - про те, що знаходиться в даному полі, - і не турбуватися про те, як результат був отриманий.
Під тілом повідомлення розуміється Зміст-Запиту чи Зміст-Відповіді відповідно. Тіло повідомлення, якщо воно присутнє, посилається в HTTP/1.0 запиті чи відповіді в форматі і кодуванні, обумовленими полями Зміст-Заголовка.
Тіла-Повідомлення = *OCTET (де OCTET це будь-який 8-бітний символ)
Тіло повідомлення включається в запит, тільки якщо метод запиту має на увазі його наявність. Для специфікації HTTP/1.0 такими методами є POST і PUT. Загалом, на присутність тіла повідомлення вказує присутність таких полів заголовка змісту, як Content-Length і/або Content- Transfer-Encoding, у переданому запиті.
Що стосується повідомлень-відповідей, наявність тіла повідомлення у відповіді залежить від методу, що був використаний у запиті, і Статус-Коду. Усі відповіді на запити HEAD не повинні містити тіло повідомлення, хоча наявність деяких полів заголовка повідомлення може вказувати на можливу присутність такого. Відповідно, відповіді "204 No Content", "304 Not Modified", і "406 None Acceptable" також не повинні містити в собі тіло повідомлення.
FORM тег визначає форму для заповнення в HTML документі. В одному документі може бути визначено кілька форм для заповнення, але вкладені FORM оператори не дозволені. Формат оператора FORM виглядає в такий спосіб:
<FORM ACTION="url" METHOD="POST">...</FORM>
Його атрибути наступні:
ACTION
URL сервера запитів, куди буде відісланий зміст форми після підтвердження. Якщо це поле відсутнє, буде використаний URL поточного документа.
METHOD
HTTP/1.0 метод використовуваний для попосилання змісту заповненої форми на сервер. Цей метод залежить від того, як працює конкретний сервер запитів. Настійно рекомендується використання методу POST. Можливі варіанти наступні:
GET - це метод за замовчуванням, що приводить до додавання вмісту заповненої форми до URL, як і в нормальному запиті.
POST при використанні цього методу вміст заповненої форми пересилається не як частина URL, а як вміст тіла запиту.
ENCTYPE
задає тип кодування вмісту заповненої форми. Цей атрибут діє тільки коли використовується метод POST і навіть у цьому випадку має тільки одне можливе значення (яке є значенням за замовчуванням)- application/x-www-form-urlencoded.
Всередині FORM оператора може знаходитися усе, що завгодно, крім іншого оператора FORM. Відповідно до специфікації, для завдання інтерфейсних елементів усередині оператора FORM використовуються теги INPUT, SELECT, і TEXTAREA.
Тег INPUT використовується для завдання простого елемента вводу усередині FORM. Це одиночний тег, його нічого не оточує і він не має закриваючого тега - тобто він використовується подібно тегу IMG.
Атрибути для тега INPUT наступні:
TYPE
повинний бути один з:
"hidden" : користувачу не пропонується поля для вводу, але вміст тега передається при підтвердженні і посилці форми. Це значення може бути використане для передачі інформації стану при взаємодії клієнта і сервера.
"image" : картинка, по якій ви можете зробити щиглика чи мишею іншим пристроєм, що вказує, що приведе до негайного підтвердження і відсилання форми. Координати обраної точки виміряються в точках від верхнього лівого кута і повертаються (поряд з іншими компонентами форми) точно так само, як для елемента Image.
"text" поле вводу тексту, значення за замовчуванням
"password" (поле вводу пароля; символи, що вводяться, представляються як зірочки)
"checkbox" (кнопка, що приймає положення on (включене) і off (виключене))
"radio" (кнопка, що приймає положення on і off; причому інші кнопки з тим же параметром NAME поводяться за принципом "одна з багатьох")
"submit" (кнопка, дія якої зводиться до відсилання вмісту заповненої форми на сервер запитів)
"reset" (кнопка, що встановлює у всіх інтерфейсних елементах значення за замовчуванням)
NAME
символічне ім'я (воно не показується) для цього поля вводу. Це поле повинне бути присутнім для всіх полів вводу крім "submit" і "reset", тому що воно використовується в рядку запиту при ідентифікації поля вводу при посилці її на сервер після підтвердження форми.
VALUE
для полів вводу тексту чи пароля, може бути використане для завдання початкового змісту поля. Для checkbox чи radio button, VALUE задає значення кнопки, коли вона знаходиться у відзначеному стані (невідмічені кнопки опускаються при посилці запиту); значення за замовчуванням для checkbox чи radio button - "on". Для типів "submit" і "reset", VALUE може бути використане для завдання напису на цих кнопках.
CHECKED (значення не потрібно)
вказує, що дана кнопка типу checkbox чи radio button відзначена за замовчуванням; це поле працює тільки для кнопок типу checkbox і radio button.
SIZE
фізичний розмір поля вводу в символах; це поле діє тільки для елементів вводу чи тексту пароля. Якщо не є присутнім явно, виставляється 20. Багатострічкові поля вводу тексту можуть бути задані за допомогою SIZE = ширина, висота; наприклад SIZE=60,12. Помітимо, що SIZE атрибут не повинний використовуватися для завдання багатострічкових полів вводу, так як можна скористатися тегом TEXTAREA.
MAXLENGTH
максимальне кількість уведених символів, що будуть прийматися для вводу, вірно тільки для полів вводу тексту і пароля (і тільки в однорядкових елементах). За замовчуванням - необмежено. Мається на увазі, що поля вводу повинні прокручуватися.
Усередині <FORM> ... </FORM>, може бути присутнім будь-яка кількість тегів SELECT, вільно перемішаних з іншими HTML елементами (включаючи INPUT і TEXTAREA елементи) і текстом (але не додаткових елементів FORM). Тег SELECT у багатьох графічних клієнтах представляється як чи меню список.
На відміну від INPUT, SELECT має відкриваючий і закриваючий теги. Всередині оператора SELECT дозволена тільки послідовність тегів OPTION, за кожним з яких випливає деяка кількість простого тексту (без HTML виразів), наприклад:
<SELECT NAME="a-menu">
<OPTION> First option.
<OPTION> Second option.
</SELECT>
Атрибути оператора SELECT наступні:
NAME
символічне ім'я для цього SELECT елемента. Це поле повинне бути присутнім, тому що воно використовується при посилці запиту (аналогічно оператору INPUT).
SIZE
якщо SIZE дорівнює 1 чи якщо цей атрибут опущений, за замовчуванням SELECT буде представлений як меню опцій Motif. Якщо SIZE = 2 чи більш, SELECT буде представлене як вікно вибору; значення SIZE тоді буде визначати, скільки елементів списку будуть видні.
MULTIPLE
якщо є присутнім (немає значення), задає, що SELECT повинен дозволяти множинний вибір зі списку. Наявність MULTIPLE примушує SELECT бути представленим як список вибору, поза залежністю від значення SIZE.
Атрибути OPTION наступні:
SELECTED задає, що ця опція обрана за замовчуванням. Якщо SELECT дозволяє множинний вибір (за допомогою атрибута MULTIPLE ), як SELECTED можуть бути позначені кілька опцій.
Тег TEXTAREA може бути використаний для розташування багатострічкового поля вводу з необов'язковим змістом за замовчуванням у формі. Атрибути тега TEXTAREA наступні:
NAME символічне ім'я поля вводу.
ROWS число рядків у поле вводу( висота).
COLS число стовпців у поле вводу (ширина).
TEXTAREA має смуги прокручування, так що може бути введена будь-яка кількість тексту. Елемент TEXTAREA вимагає і відкриваючий і закриваючий теги. TEXTAREA без змісту за замовчуванням виглядає приблизно так:
<TEXTAREA NAME="foo" ROWS=4 COLS=40></TEXTAREA>
TEXTAREA зі змістом за замовчуванням виглядає так:
<TEXTAREA NAME="foo" ROWS=4 COLS=40> Default contents go here. </TEXTAREA>
Зміст за замовчуванням повинен бути строгим ASCII текстом. Символи перекладу рядка сприймаються (так що в прикладі вище до і після тексту "Default contents go here." буде порожній рядок).
Для методу GET
Коли натискається кнопка submit, уміст форми буде додане до URL у наступній формі:
action?name=value&name=value&name=value
(тут "action" - URL, задане атрибутом ACTION у тегі FORM, чи URL поточного документа, якщо атрибут ACTION не був заданий).
Нестандартні символи в прикладах "name" чи "value" будуть опущені, при цьому маються на увазі також "=" and "&". Це означає, що включення "=", що розділяють імена і значення (names і values), і включення "&", що розділяють пари name/value, не опускаються.
Для полів вводу тексту і пароля, значенням буде те, що введе користувач. Якщо користувач залишить це поле порожнім, значення value також буде порожнім , але в рядку запиту буде присутній фрагмент "name=".
Для кнопок типу checkbox і radio button, значення value визначається атрибутом VALUE у тому випадку, коли кнопка відзначена. Невідмічені кнопки при складанні рядка запиту ігноруються цілком. Кілька кнопок типу checkbox можуть мати один атрибут NAME (і різні VALUE), якщо це необхідно. Кнопки типу radio button призначені для того, щоб поводитися за принципом "одна з усіх" і повинні мати однаковий атрибут NAME і різні атрибути VALUE.
Для методу POST
Зміст форми кодується точно як для методу GET (див. вище), але замість додавання змісту форми до URL, заданої атрибутом форми ACTION, як запит, зміст посилається блоком даних як частина операції POST. Якщо є присутнім атрибут ACTION, то значення URL, що там знаходиться, визначає, куди послати цей блок даних. Цей метод особливо рекомендується при посилці великих блоків даних.
New art Database 2 Free art Database