Цілі, Протоколи, Інтернет-технології, статті

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 запит







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


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

 Запит = Простий-Запит | Повний-Запит
Простий-Запит = "GET" SP Запитуваний-URI CRLF
Повний-Запит = Рядок-Статус
* (Загальний-Заголовок | Заголовок-Змісту ) CRLF
[ GET" | "PUT" | "DELETE" | "UNLINK"
| Додатковий-метод

Список методів, що допускаються окремим ресурсом, може бути зазначений у полі
Заголовок-Зміст "Балів". Тим не менш, клієнт завжди оповіщається сервером
через код статусу відповіді, чи допускається застосування даного методу для
вказаного ресурсу, тому що допустимість застосування різних методів може
динамічно змінюватися. Якщо даний метод відомий серверу, але не допускається
для зазначеного ресурсу, сервер повинен повернути код статусу "405 Method Not
Allowed ", і код статусу" 501 Not Implemented ", якщо метод не відомий або не
підтримується даним сервером. Загальні методи HTTP/1.0 описуються нижче.



GET


Метод GET служить для одержання будь-якої інформації, ідентифікованої
URI-запиту. Якщо URI-Запиту посилається на процес, що видає дані, як
відповіді будуть виступати дані, згенеровані даним процесом, а не код самого
процесу (якщо тільки це не є вихідними даними процесу).


Метод GET змінюється на "умовний GET", якщо повідомлення запиту містить у
себе поле заголовка "If-Modified-Since". У відповідь на умовний GET, тіло
запитуваного ресурсу передається тільки, якщо він змінювався після дати,
вказаної в заголовку "From |
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-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 = "User-Agent" ":" 1 * (продукт)
продукт = рядок ["/" версія-продукту]
версія-продукту = рядок

Приклад:


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


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


HTTP відповідь







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


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

 Відповідь = Простий-Відповідь | Повна-Відповідь
Простий-Відповідь = [Зміст-Відповіді]
Повний-Відповідь = Заголовок-Відповіді | Зміст-Відповіді ]

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



Рядок Статус


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


Рядок-Статус = Версія-HTTP SP Статус-Код SP
Фраза-Про "яснення.


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



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


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


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



  1. 1xx: Інформаційний – Не використовується, але зарезервований для використання в
    майбутньому
  2. 2xх: Успіх – Запит був цілком отриманий, зрозумілий, і прийнятий до обробки.
  3. 3xx: Перенаправлення – Клієнту варто почати подальші дії для
    успішного виконання запиту. Необхідна додаткова дія іноді може
    бути виконано клієнтом без взаємодії з користувачем, але настійно
    рекомендується, щоб це мало місце тільки в тих випадках, коли метод,
    використовується в запиті байдужий (GET або HEAD).
  4. 4xx: Помилка клієнта – Запит, що містить неправильні синтаксичні
    конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису
    тих випадків, коли помилка була допущена з боку клієнта. Якщо клієнт ще не
    завершив запит, коли він отримав відповідь з Статус-Кодом-4xx, він повинен
    негайно припинити передачу даних серверу. Даний тип Статус-Кодів застосуємо
    для будь-яких методів, що вживаються в запиті.
  5. 5xx: Помилка Сервера – Сервер не зміг дати відповідь на коректно поставлений
    запит. У цих випадках
  6. сервер або знає, що він допустив помилку, або не здатний обробити
    запит. За винятком відповідей на запити 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.


Зміст Запиту і Зміст Відповіді







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


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


Поля Заголовок-Змісту


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

 Заголовок-Змісту = Content-Length |
Content-Transfer-Encoding | Last-Modified |Link |
Location | Title | URI-header | Version | Заголовок-Розширення
Заголовок-Розширення = HTTP-заголовок

Деякі з полів заголовка змісту описані нижче.


Allow


Поле заголовка Allow являє собою список методів, які підтримує
ресурс, ідентифікований URI-запиту. Призначення цього поля – точне
інформування одержувача про допустимі методи, асоційовані з ресурсом; це
поле повинне бути присутнім у відповіді з статус кодом "405 Method Not Allowed".


Allow = "Allow" ":" 1 # метод


Приклад використання:


Allow: GET, HEAD, PUT


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


Content-Length


Поле Content-Length указує розмір тіла повідомлення, посланого сервером у
відповідь на запит або, в разі запиту HEAD, розмір тіла повідомлення, яке було
б послано у відповідь на запит GET.


Content-Length = "Content-Length" ":" 1 * ЦИФРА


Наприклад:


Content-Length: 3495


Хоча це не обов'язково, але все ж додаткам настійно рекомендується
використовувати це поле для аналізу розмірів переданого повідомлення, незалежно
від типу міститься в ньому. Для поля Content-Length допустимим
є будь цілочисельне значення більше нуля.


Content-Type


Поле заголовка Content-Type ідентифікує тип інформації в тексті повідомлення,
яка надсилається стороні, що одержує або, у випадку методу HEAD, тип інформації
(Середовища), який був би посланий, якщо використовувався метод GET.


Content-Type = "Content-Type" ":" тип-середовища


Типи середовищ визначені окремо.
Приклад:


Content-Type: text/html; charset=ISO-8859-4


Поле Content-Type не має значення за замовчуванням.


Last-Modified


Поле заголовка містить дату і час, в яке, на думку отправляющей
боку, ресурс був останній раз модифікований. Семантика даного поля
визначена в термінах, що описують, як одержувач повинен його інтерпретувати:
якщо одержувач має копію ресурсу, яка старше, ніж передана в поле
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" також не
повинні включати в себе тіло повідомлення.

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


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

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

Ваш отзыв

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

*

*