2.6.4. HyperText Transfer Protocol - протокол обміну WWW - серверів

Мети

HyperText Transfer Protocol (HTTP) - це протокол високого рівня (асаме, рівня додатків), що забезпечує необх дну швидк сть передач даних, що вимагається для розпод лених нформац йних систем гіпермедіа. HTTP використовується проектом World Wide Web з l990 року. Практичн нформац йн системи вимагають б льшого, н ж прим тивний пошук, модиф кац я й анотац я даних. HTTP/l.0 надає в дкрита безл ч метод в, що можуть бути використан для вказ вки цілей запиту. Вони побудовані на дисципліні посилань, де для вказівки ресурсу, до якого повинний бути застосований даний метод, використовується Універсальний Ідентифікатор Ресурсів (Universal Resource Identifier - URI), увиді місцезнаходження (ШІ^^и імені (URN). Формат повідомлень подібний зформатом Internet Mail чи Multipurpose Internet Mail Extensions (MIME-багатоцільове Розширення Пошти Internet).

HTTP/l.0 використовується також для комунікацій між різними користувальницькими переглядачами ішлюзами, що дають гіпермедіа доступ до існуючих Internet протоколам, таким як SMTP, NNTP, FTP, Gopher і WAIS. HTTP/l.0 розроблений, щоб дозволяти таким шлюзам через proxy сервери, без якої-небудь утрати передавати дан за допомогою згаданих протокол в б льш ранн х верс й.

Загальна Структура

HTTP ґрунтується на парадигмі запитів/відповідей. Запитуюча програма (звичайно вона називається клієнт) установлює зв'язок зобслуговуючої програмою-одержувачем (звичайно називається сервер ) і надсилає запит серверу в наступній формі: метод запиту, URI, версія протоколу, за якої випливає MIME-подібне повідомлення, що містить керуючу інформацію запиту, інформацію про клієнта і, може бути, т ло пов домлення. Сервер в дпов дає пов домленням, що м стить рядок статусу (включаючи вер сію пр отоколу ікод статусу - чи успіх по милка), за якого випливає MIME-подібне повідомлення, що включає всебе інформацію про сервер, метаінформацію про зміст відповіді, і, імовірно, саме тіло відповіді. Слід зазначити, що одна програма може бути одночасно іклієнтом і сервером. Використання цих термінів уданому тексті відноситься тільки до ролі, виконуваною програмою протягом даного конкретного сеансу зв'язку, ане до загальних функц й програми. У Internet комунікації звичайно ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням - TCP 80, але також можуть бути використан й ншогономера порт в - це не виключає можливост використовувати HTTP як протокол верхнього р вня.

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

HTTP запит

Загальні поняття

Запит - це пов домлення, що посилається кл єнтом серверу.

Перший рядок цього пов домлення м стить усоб метод, що повинний бути застосований до запитуваного ресурсу, дентиф катор ресурсу  використовувану верс ю протоколу. Для сум сност з протоколом HTTP/0.9, снує два формати HTTP запиту:

Запит = Пр остій-Запит І Повн-Запит Простій-Запит = "GET" SP Запитуваний-URI CRLF Повн-Запит = Рядок-Статус

*(Загальн-Заголовок І Заголовка-Запиту І Заголовка-Змісту ) CRLF [ Змісту-Запиту J

Якщо HTTP/l.0 сервер одержує Простій-Запит, він повинний відповідати Прост-Відповіддю HTTP/0.9. HTTP/l.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", ікод статусу "50l Not Implemented", якщо метод чи не відомий не підтримується даним сервером. Загальні методи HTTP/l.0 описуються нижче.

GET

Метод GET служить для одержання будь-якої інформації, ідентифікованої URI-запиту. Якщо URI-Запиту посилається на процес, що видає дан , як в дпов дь будуть виступати дан , сгенерован даним процесом, ане код самого процесу (якщо тільки це не є вихідними даними процесу). Метод GET змінюється на "умовний GET", якщо повідомлення запиту містить усобі поле заголовка "If-Modified-Since". У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, зазначеної в заголовку "If-M odified-Since".Алгоритм визначення цього м стить усоб наступн випадки:

• Якщо код статусу відповіді на запит буде відрізнятися від "200 OK", чи дата, зазначена в поле заголовка "If-Modified-Since" некоректна, відповідь буде ідентичний відповіді на звичайний запит GET.

• Якщо після зазначеної дати ресурс змінювався, відповідь буде також ідентичний відповіді на звичайний запит GET.

• Якщо ресурс не змінювався після зазначеної дати, сервер поверне код статусу "304 Not Modified".

Використання методу умовний GET спрямовано на розвантаження мереж , тому що в н дозволяє не передавати по мереж надлишкову нформац ю.

HEAD

Метод HEAD аналогічний методу GET, за винятком того, що увідповіді сервер не повертає Тіло-Відповіді. Метаінформація, що міститься в HTTP заголовках відповіді на запит HEAD, повинна бути дентична нформац ї HTTP заголовк в в дпов д на запит GET. Даний метод може використовуватися для одержання мета нформац ї про ресурс без передач по мереж самого ресурсу. Метод "Умовний HEAD", аналогічний умовному GET, не визначений.

POST

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

• Анотац я снуючих ресурс в

• Додавання пов домлень угрупи новин, поштов чи списки под бн групи статей

• Доставка блок в даних процесам, що обробляють дан

• Розширення баз даних через операцію додавання

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

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

Якщо в результаті обробки запиту POST був створений новий ресурс, відповідь повинна мати код статусу, рівний "201 Created", іміститиURI нового ресурсу.

PUT

Метод PUT запитує сервер про збереження Тіла-Запиту під URI, рівним URI-запиту. Якщо URI-запиту посилається на вже снуючий ресурс, T ла-Запиту повинне розглядатися як модиф кована версія даного ресурсу. Якщо ресурс, на який посилається URI-запиту не існує, іданий URI може розглядатися як опис для нового ресурсу, сервер може створити ресурс з даним URI. Якщо був створений новий ресурс, сервер повинний нформувати запит кл єнта, що направив, через в дпов дь зкодом статусу "201 Created". Якщо існуючий ресурс був модифікований, повинний бути послана відповідь "200 OK", для інформування клієнта про успішне завершення операції. Якщо ресурс із зазначеним URI не може бути створений чи модиф кований, повинне бути послане в дпов дне пов домлення про помилку.

Фундаментальне розходження м ж методами POST PUT полягає вр зному значенн полючи URI-запиту. Для методу POST даний URI указує ресурс, що буде керувати інформацією, що міститься в тілі запиту, як деяким придатком. Ресурс може бути обробним дані процесом, шлюзом уякий-небудь нший протокол, чи окремим ресурсом, що допускає анотац ї. На противагу цьому, URI для запиту PUT ідентифікує інформацію, що міститься вЗмісту -Запиту. Запит, що використовує, PUT точно знає який URI в н збирається використовувати,  одержувач запиту не повинний намагатися застосувати цей запит до якого-небудь ншого ресурсу.

DELETE

Метод DELETE використовується для видалення ресурсів, ідентифікованих за допомогою URI-запиту . Результати роботи даного методу на сервері можуть бути змінені за допомогою людського втручання (чи яким-небудь іншим способом). У принципі, клієнт ніколи не може бути упевнений, що операц я видалення була виконана, нав ть якщо код статусу, переданий сервером, нформує про успішне виконання дії. Проте, сервер не повинний інформувати про успіх доти, поки на момент в дпов д в н не буде збиратися стерти даний чи ресурс перем стити його вдеяку недосяжну область.

LINK

Метод LINK установлює взаємозв'язку між існуючим ресурсом, зазначеним у URI-запиту, і іншими існуючими ресурсами. Відмінність методу LINK від інших методів, що допускають установлення посилань м ж документами, полягає вт м, що метод LINK не дозволяє передавати взапит T ла-Запиту, в т м, що в результат роботи даного методу не створюються нов ресурси.

UNLINK

Метод UNLINK видаляє одну чи б льш посилальних взаємозв'язк в для ресурсу, зазначеного в URI-Запиту. Ц взаємозв'язки можуть бути встановлен за допомогою методу LINK чи якого-небудь ншого методу, що п дтримує заголовок "Link". Видалення посилання на ресурс не означає, що ресурс припиняє чи снування стає недоступним для майбутн х посилань.

Поля Заголовка-Запиту

Поля Заголовка-Запиту дозволяють клієнту передавати серверу додаткову інформацію про запит і про самого кл єнта.

Заголовка-Запиту = Accept І Accept-Charset І Accept-Encoding І Accept-Language І Authorization І From І If-Modified-Since І

Pragma І Referer І User-Agent І extension-header

Кр м того через механ зм розширення можуть бути визначен додатков заголовки; додатка, що їхн й не розп знають, повинн трактувати ц заголовки, як Заголовок-Зм ст. Нижче будуть розглянут деяк полючи заголовка запиту. From

У випадку присутност полючи From, воно повинно м стити повний E-mail адресу користувача, що керує програмою-агентом, що зд йснює запити. Ця адреса повинна бути задана уформат , визначеному в RFC 822. Формат даного полючи наступний: From = "From" ":" специф кац я адреси. Наприклад:

From: webmaster@WWW.org

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

Зауваження: Клієнт не повинний використовувати поле заголовка From без дозволу користувача, тому що це може ввійти в конфлікт із його приватними чи інтересами з місцевої, використовуваної ним, системою безпеки. Наст йно рекомендується надання користувачу можливост заборонити, чи дозволити модифікувати це поле вбудь-який момент перед запитом. If-Modified-Since

Поле заголовка If-M odified-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 = "User-Agent" ":" 1*( продукт ) продукт = рядок ["/" версії-продукту ] верс ї-продукту = рядок

Інформаційні Технології О.В.Стрельцов 51

Приклад:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

HTTP відповідь Структура відповіді

Після одержання й інтерпретації попиту, сервер посилає відповідь у відповідності знаступною формою:

В дпов дь = Прост й-В дпов дь І Повн-В дпов дь Прост й-В дпов дь = [ Зм сту-В дпов д ] Повн-В дпов дь = Рядок-Статус

*( Загальн-Заголовок І Заголовка-Відповіді І Заголовка-Змісту) CRLF [ Зм сту-В дпов д ]

Простій-Відповідь повинна посилатися тільки увідповідь на HTTP/0.9 Простій-Запит, чи втому випадку, якщо сервер підтримує тільки обмежений HTTP/0.9 протокол. Якщо клієнт посилає HTTP/1.0 Повн-Запит іодержує відповідь, що не починається з Строки-Статус, він повинний припускати, що в дпов дь сервера являє собою Прост й-В дпов дь,  обробляти його в дпов дно до цього. Варто пом тити, що Прост й-В дпов дь складається т льки з запитуваної нформац ї (без заголовків) іпотік даних припиняється втой момент, коли сервер закриває сеанс зв'язку.

Рядок Статус

Перший рядок Повн-Запиту єРядок-Статус, що складається з версії протоколу, за якого випливає цифровий код статусу й асоц йоване знимтекстова пропозиц я. Вс елементи Рядок-Статус розділені пробілами. Не дозволені символи CR і LF, за винятком завершальної послідовності CRLF. Pydod-Cmamyc=Bepciy-HTTP SP Статус-Код SP Фраза-Пояснюеання.

Тому що Рядок-Статус завжди починається з версії протоколу "HTTP/" 1*ЦИФРА "." 1*ЦИФРА (наприклад HTTP/1.0), існування цього вираження розглядається як основне для визначення того, чи є відповідь Прост-Відповіддю, чи Повн-Відповіддю. Хоча формат Прост-Відповіді не виключає появи подібного рядка (що привело бдо неправильної штрпретації повідомлення відповіді і прийняттю його за Повн-В дпов дь), мов рн сть такої появи близька до нуля.

Статус-Код і пояснення до нього

Елемент Статус-Код являє собою 3-х цифровий цілий код, що ідентифікує результат спроби нтерпретац ї задоволення запиту. Фраза-Пояснювання, що випливає за ним, призначена для короткого текстового опису Статус-Коду. Статус-Код нац лен на те, щоб його використовувала машина, аФраза-Пояснювання призначена для людини. Кл єнт не зобов'язаний досл джувати виводити на екран Фразу-Пояснювання.

Перша цифра Статус-Коду призначена для визначення класу відповіді. Останні дві цифри не виконують н який категор зиючої рол . Існує 5 значень для першої цифри:

1. 1xx: Інформац йний - Не використовується, але зарезервований для використання в майбутньому

2. 2хх Успіх - Запит був цілком отриманий, зрозумілий, і прийнятий до обробки.

3. Зхх: Перенапрямок - Клієнту варто почати подальші дії для успішного виконання запиту. Необхідна додаткова дія іноді може бути виконано клієнтом без взаємодії з користувачем, але настійно рекомендується, щоб це мало місце тільки втих випадках, коли метод, що використовується в запиті байдужний (GET чи HEAD).

4. 4хх: Помилка клієнта - Запит, що містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4хх призначений для опису тих випадків, коли помилка була допущена збоку кл єнта. Якщо кл єнт ще не завершив запит, коли в н одержав в дпов дь з Статус-Кодом- 4хх, в н повинний негайно припинити передачу даних серверу. Даний тип Статус-Код в застосуємо для будь-яких метод в, що вживаються в запит .

5. 5хх: Помилка Сервера - Сервер не зміг дати відповідь на коректно поставлений запит. Уцих випадках

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

Окрем значення Статус-Код в в дпов дн їм Фразы-Пояснювання приведен нижче. Дан Фразы-Пояснювння т льки рекомендуються - вони можуть бути зам щен будь-якими ншими фразами, що збер гають зм ст допускаються протокол.

Статус-Код = "200" ; OK І

"201" ; Created І

"202" ; Accepted І

"203" ; Provisional Information І

"204" ; No Content І

300

302 303 304

; Multiple Choices

"301" ; Moved Permanently | ; MovedTemporarily | ; Method | ; 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 додатків не потрібно розуміння всіх Статус-Кодів, хоча таке розуміння, мабуть, бажано. Проте, в д додатк в потр бно здатн сть розп знавання клас в Статус-Код в (що ідентифікуються першою цифрою) і відношення до всіх Статус-Кодів статусу відповіді, як якби вони були екв валентн Статус-Коду х00. Поля Заголовка-Відповіді

Поля заголовка в дпов д дозволяють серверу передати додаткову нформац ю про в дпов дь, що не може бути внесена вРядок-Статус. Ц полючи заголовк в не призначен для передач інформації про зміст відповіді, переданого увідповідь на запит, але там може бути нформац я власне про сервер.

Загoлoeка-Biдnoeiдi= Public \ Retry-After \ Server \ WWW-Authenticate \ extension-header

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