Протокол HTTP

 

Лекція 5

Протокол HTTP

1. Призначення протоколу

2. Загальна структура

3. HTTP запит

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

б) Строка Статус.

в) Метод запиту

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

4. HTTP відповідь.

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

б) Рядок Статус.

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

г) Поля заголовка відповіді

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

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

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

Отримання інформації з мережі Internet на даному етапі розвитку інформаційних технологій є надзвичайно розповсюдженим явищем. Кожен, хто хоча б раз працював у мережі зіштовхувався із цим. Щохвилини десятки тисяч гігабіт інформації пересилається через Internet. Це здійснюється за допомогою спеціальних програм, таких, як броузери: Internet Explorer, Netscape Navigator, Opera та інш.; таких, як менеджери завантаження: Reget, FlashGet, Gozzila та інш. Інформація також передається через електронну пошту, Internet-телефонію та інш. Роботу цих програм забезпечують спеціальні протоколи. Одним з таких протоколів є протокол HTTP.

На даному етапі він відіграє дуже важливу роль в передачі інформації. Більшість інформації, яка передається по Internet передається з допомогою HTTP. Раніше цей протокол використовувався лише для передачі інформації невеликих розмірів (текстових файлів, рисунків і т.д.). За передачу більших файлів відповідав протокол FTP (File Transfer Protocol). Зараз по HTTP передаються файли довільних розмірів і він є основним протоколом, який за це відповідає.

І. ПРОТОКОЛ HTTP

1. Призначення протоколу.

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 сервери, без якої-небудь утрати передавати дані за допомогою згаданих протоколів більш ранніх версій.

2. Загальна структура.

HTTP ґрунтується на парадигмі запитів/відповідей. Запитуюча програма (як правило вона називається клієнт) встановлює зв’язок з обслуговуючою програмою-одержувачем (що називається сервер) і надсилає запит серверу в наступній формі:

  • метод запиту,
  • URI,
  • версія протоколу,
  • за якою слідує MIME-подібне повідомлення, що містить керуючу інформацію запиту, інформацію про клієнта і, можливо, тіло повідомлення.

Сервер відповідає повідомленням, що містить рядок статусу (включаючи версію протоколу і код статусу – успіх чи помилка), за якого слідує MIME повідомлення, що включає в себе інформацію про сервер, метаінформацію про зміст відповіді, і, можливо, саме тіло відповіді. Слід зазначити, що одна програма може бути одночасно і клієнтом і сервером. Використання цих термінів у даному тексті відноситься тільки до ролі, що виконує програма протягом даного конкретного сеансу зв’язку, а не до загальних функцій програми.

Internet комунікації звичайно ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням — TCP:80, але також можуть бути використані й інші номера портів — це не виключає можливості використовувати HTTP як протокол верхнього рівня.

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

3. 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

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

Метод GET змінюється на “умовний GET”, якщо повідомлення запиту містить у собі поле заголовка “If-Modified-Since”. У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, зазначеної в заголовку “If-Modified-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-запиту посилається на вже існуючий ресурс, Тіло-Запиту повинне розглядатися як модифікована версія даного ресурсу. Якщо ресурс, на який посилається 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 не дозволяє передавати в запиті Тіло-Запиту, і в тому, що в результаті роботи даного методу не створюються нові ресурси.

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

4. HTTP відповідь.

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

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

 Відповідь = Проста-Відповідь | Повна-Відповідь
 Проста-Відповідь = [ Зміст-Відповіді ]
 Повна-Відповідь = Рядок-Статус
*( Загальний-Заголовок | Заголовок-Відповіді | Заголовок-Змісту) CRLF
                        [ Зміст-Відповіді ]

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

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

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

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

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

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

 Заголовок-Змісту = 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

Поле заголовка 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” також не повинні містити в собі тіло повідомлення.