2.4. Поля заголовка запиту

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

Нижче будуть розглянуті деякі поля заголовка запиту.

From

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

наприклад:

From: Ця електронна адреса захищена від спам-ботів. У вас повинен бути включений JavaScript для перегляду.

Дане поле може бути використане для функцій заходу в систему, а також для ідентифікації джерела некоректних або небажаних запитів. Воно не повинно використовуватися, як несекретна форма розмежування прав доступу. Інтерпретація цього поля полягає в тому, що обробляється запит виробляється від імені даного користувача, який приймає відповідальність за застосовуваний метод. Зокрема, агенти-роботи повинні використовувати цей заголовок для того, щоб можна було зв'язатися з тією людиною, яка відповідає за роботу робота, в разі виникнення проблем. Поштовий 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 1 994 19:43:31 GMT

Метою цієї особливості є надання можливості ефективного відновлення інформації локальних кешей з мінімумом переданої інформації. Той же результат може бути досягнутий застосуванням методу HEAD з наступним використанням GET, якщо сервер вказав, що вміст документа змінився.

User-Agent

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

приклад:

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

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

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

3.1. структура відповіді

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

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

3.2. рядок Статус

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

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

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

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

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

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

1. 1xx: Інформаційний - Чи не вікорістовується, но зарезервованій для использование в Майбутнього
2. 2xх: Успіх - Запитів БУВ Цілком отриманий, зрозумілій, и чинний до ОБРОБКИ.
3. 3xx: Перенаправлення - Клієнту варто почати подальші дії для успішного виконання запиту. Необхідна додаткова дія іноді може бути виконано клієнтом без взаємодії з користувачем, але настійно рекомендується, щоб це мало місце лише в тих випадках, коли метод, що використовується в запиті байдужий (GET або HEAD).
4. 4xx: Помилка клієнта - Запит, що містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису тих випадків, коли помилка була допущена з боку клієнта. Якщо клієнт ще не завершив запит, коли він отримав відповідь з Статус-Кодом- 4xx, він повинен негайно припинити передачу даних серверу. Даний тип Статус-Кодів можна застосувати для будь-яких методів, що вживаються в запиті.
5. 5xx: Помилка Сервера - Сервер не зміг дати відповідь на коректно поставлений запит. У цих випадках
6. сервер або знає, що він припустився помилки, або не здатний обробити запит. За винятком відповідей на запити HEAD, сервер посилає опис помилкової ситуації і те, чи є цей стан тимчасовим або постійним, в Зміст-Відповіді. Даний тип Статус-Кодів можна застосувати для будь-яких методів, що вживаються в запиті.

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

Від HTTP додатків не потрібно розуміння всіх Статус-Кодів, хоча таке розуміння, очевидно, бажано. Проте, від додатків вимагається здатність розпізнавання класів Статус-Кодів (ідентифікуються першою цифрою) і відношення до всіх Статус-кодами статусу відповіді, як якби вони були еквівалентні Статус-Коду x00.

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

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

Заголовок-Відповіді = Public | Retry-After | Server | WWW-Authenticate | extension-header

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

4. Зміст запиту і відповіді

Як видно на малюнку всі транзакції між клієнтом і сервером відбуваються на верхньому рівні мережевий ієрархії. Всі HTTP-транзакції мають один загальний формат. Кожен запит клієнта і відповідь сервера складається з трьох частин: рядки запиту (відповіді), розділу заголовка і тіла.

Клієнт ініціює транзакцію наступним чином:

1. Клієнт встановлює зв'язок з сервером на номер телефону порту (за замовчуванням - 80). Потім надсилається запит документа із зазначенням HTTP комманди (званої методом), адреси документа і номера версії HTTP. Наприклад: GET /index.html HTTP / 1.0
2. Клієнт посилає необов'язкову інформацію заголовка, щоб повідомити серверу інформацію про свою конфігурації і дані про форматах документів, які він може приймати. Вся інформація заголовка вказується за рядком і кожен рядок містить пару ім'я-значення. Тема завершується символом нового рядка. Наприклад: User-Agent: Mozilla / 2.02Gold (WinNT; I)
   Accept: image / gif, image / jpeg, * / *
3. Надіславши запит і заголовки, клієнт може відправити додаткові дані (тіло запиту). Ці дані використовуються, наприклад, CGI-програмами, які застосовують метод POST.

Сервер відповідає на запит клієнта наступним чином:

1. Перша частина відповіді - рядок стану, що містить версію протоколу HTTP, код стану та опис, яке представляє собою просто зрозумілий для людини текст, що пояснює код стану. Наприклад: HTTP / 1.0 200 OK
2. Після рядка стану сервер передає клієнту інформацію заголовка відповіді, що містить дані про самому сервері і викликаній документі. Завершує заголовок порожній рядок. Наприклад: Date: Fri, 20 Sep 1996 8:17:58 GMT
   Server: NCSA / 1.5.2
   Last-modified: Mon, 17 Jun 1 996 21:53:08 GMT
   Content-type: text / html
   Content-length: 2482
3. Якщо запит клієнта успішний, то сервер посилає витребувані дані. Це може бути копія файлу або документ сформований "на льоту". Якщо запит клієнта задовольнити не можна, то сервер передає додаткові дані у вигляді зручного для людини роз'яснення причин, за якими сервер не зміг виконати запит.

У HTTP 1.0 після передачі сервером затребуваних даних слід роз'єднання з клієнтом і транзакція завершується, якщо не був переданий заголовок Connection: Keep Alive. У HTTP 1.1 сервер за замовчуванням не розриває з'єднання і клієнт може посилати інші запити. Це дозволяє заощадити час і витрати клієнта, якому не доводиться заново з'єднуватися з тим же сервером. Таким чином, в HTTP 1.1 транзакція може циклічно повторюватися, поки клієнт або сервер не закриє з'єднання явно.

4.1. методи

Метод - це HTTP-комманда, з якої починається перший рядок запиту клієнта. Метод повідомляє серверу про мету запиту. Найчастіше використовуються методи GET, HEAD і POST (реєстр має значення).

• час зміни документа;
• розмір документа;
• Тип документа;
• тип сервера.

Слід зазначити, що більша частина посилається сервером інформації заголовка, не є обов'язковою і може представлятися не всіма web серверами. например:

• мережевих служб (наприклад телеконференцій)
• програм з інтерфейсом типу "командний рядок"
• виконання операцій в базах даних

например:

test = 20 & test2 = 22