Цілі

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
[Зміст-Запиту]

Якщо 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.
Алгоритм визначення цього включає в себе наступні випадки:




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


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


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







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


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


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


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

 Заголовок-Змісту = 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" також не
повинні включати в себе тіло повідомлення.

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


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

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

Ваш отзыв

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

*

*