Протокол HTTP - Документація по Веб-програмування 0.0.0

1. структура протоколу
2. Стартовий рядок HTTP
3. методи протоколу
4. коди стану
5. заголовки HTTP
6. тіло повідомлення
7. контрольні питання

HTTP (HyperText Transfer Protocol - протокол передачі гіпертексту) - символьно-орієнтований клієнт-серверний протокол прикладного рівня без збереження стану, який використовується сервісом World Wide Web.

Основним об'єктом маніпуляції в HTTP є ресурс, на який вказує URI (Uniform Resource Identifier - унікальний ідентифікатор ресурсу) в запиті клієнта. Основними ресурсами є що зберігаються на сервері файли, але ними можуть бути і інші логічні (напр. Каталог на сервері) або абстрактні об'єкти (напр. ISBN). Протокол HTTP дозволяє вказати спосіб представлення (кодування) одного і того ж ресурсу за різними параметрами: mime-типу, мови і т. Д. Завдяки цій можливості клієнт і веб-сервер можуть обмінюватися двійковими даними, хоча даний протокол є текстовим.

структура протоколу

Структура протоколу визначає, що кожне HTTP-повідомлення складається з трьох частин (рис. 1), які передаються в наступному порядку:

1. Стартовий рядок (англ. Starting line) - визначає тип повідомлення;
2. Заголовки (англ. Headers) - характеризують тіло повідомлення, параметри передачі та інші відомості;
3. Тіло повідомлення (англ. Message Body) - безпосередньо дані повідомлення. Обов'язково повинно відділятися від заголовків порожнім рядком.

Мал. 1. Структура протоколу HTTP (дамп пакету, отриманий сніффером Wireshark)

Стартовий рядок HTTP

Стартовий рядок є обов'язковим елементом, так як вказує на тип запиту / відповіді, заголовки і тіло повідомлення можуть бути відсутні.

Стартові рядки розрізняються для запиту і відповіді. Рядок запиту виглядає так:

Метод URI HTTP / Версія протоколу

Приклад запиту:

GET /web-programming/index.html HTTP / 1.1

Стартовий рядок відповіді сервера має наступний формат:

HTTP / Версія КодСостоянія [Пояснення]

Наприклад, на попередній наш запит клієнтом даної сторінки сервер відповів рядком:

HTTP / 1.1 200 Ok

методи протоколу

Метод HTTP (англ. HTTP Method) - послідовність з будь-яких символів, крім керуючих і роздільників, яка вказує на основну операцію над ресурсом. Зазвичай метод являє собою короткий англійське слово, записане великими літерами (Табл. 1). Назви методу чутливі до регістру.

Таблиця 1. Методи протоколу HTTP

Метод Короткий опис OPTIONS

Використовується для визначення можливостей веб-сервера або параметрів з'єднання для конкретного ресурсу. Передбачається, що запит клієнта може містити тіло повідомлення для вказівки цікавлять його відомостей. Формат тіла і порядок роботи з ним зараз не визначений. Сервер поки повинен його ігнорувати. Аналогічна ситуація і з тілом у відповіді сервера.

Для того щоб дізнатися можливості всього сервера, клієнт повинен вказати в URI зірочку - «*». Запити «OPTIONS * HTTP / 1.1» можуть також застосовуватися для перевірки працездатності сервера (аналогічно «пингования») і тестування на предмет підтримки сервером протоколу HTTP версії 1.1.

Результат виконання цього методу не кешируєтся.

Використовується для запиту вмісту зазначеного ресурсу. За допомогою методу GET можна також почати будь-який процес. В цьому випадку в тіло листа у відповідь слід включити інформацію про хід виконання процесу. Клієнт може передавати параметри виконання запиту в URI цільового ресурсу після символу «?»: GET / path / resource? Param1 = value1¶m2 = value2 HTTP / 1.1

Відповідно до стандарту HTTP, запити типу GET вважаються Ідемпотентний [4] - багаторазове повторення одного і того ж запиту GET повинне приводити до однакових результатів (за умови, що сам ресурс не змінився за час між запитами). Це дозволяє кешувати відповіді на запити GET.

Крім звичайного методу GET, розрізняють ще умовний GET і частковий GET. Умовні запити GET містять заголовки If-Modified-Since, If-Match, If-Range і подібні. Часткові GET містять в запиті Range. Порядок виконання подібних запитів визначено стандартами окремо.

HEAD

Аналогічний методу GET, за винятком того, що у відповіді сервера відсутнє тіло. Запит HEAD зазвичай застосовується для вилучення метаданих, перевірки наявності ресурсу (валідація URL) і щоб дізнатися, чи не змінився він з моменту останнього звернення.

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

Застосовується для передачі призначених для користувача даних заданому ресурсу. Наприклад, в блогах відвідувачі зазвичай можуть вводити свої коментарі до записів в HTML-форму, після чого вони передаються сервера методом POST і він поміщає їх на сторінку. При цьому передані дані (в прикладі з блогами - текст коментаря) включаються в тіло запиту. Аналогічно за допомогою методу POST зазвичай завантажуються файли.

На відміну від методу GET, метод POST не рахується ідемпотентна [4], тобто багаторазове повторення одних і тих же запитів POST може повертати різні результати (наприклад, після кожної відправки коментаря з'являтиметься одна копія цього коментаря).

При результатах виконання 200 (Ok) і 204 (No Content) в тіло відповіді слід включити повідомлення про підсумок виконання запиту. Якщо був створений ресурс, то сервера слід повернути відповідь 201 (Created) із зазначенням URI нового ресурсу в заголовку Location.

Повідомлення відповіді сервера на виконання методу POST НЕ кешується.

Застосовується для завантаження вмісту запиту на вказаний в запиті URI. Якщо по заданому URI не існувало ресурсу, то сервер створює його і повертає статус 201 (Created). Якщо ж був змінений ресурс, то сервер повертає 200 (Ok) або 204 (No Content). Сервер не повинен ігнорувати некоректні заголовки Content- * передаються клієнтом разом з повідомленням. Якщо якийсь з цих заголовків не може бути розпізнаний або не допустимо при поточних умовах, то необхідно повернути код помилки 501 (Not Implemented).

Фундаментальна відмінність методів POST і PUT полягає в розумінні призначень URI ресурсів. Метод POST передбачає, що за вказаною URI буде проводитися обробка переданого клієнтом вмісту. Використовуючи PUT, клієнт передбачає, що завантажувати вміст відповідають знаходиться за даним URI ресурсу.

Повідомлення відповідей сервера на метод PUT НЕ кешуються.

PATCH

Аналогічно PUT, але застосовується тільки до фрагменту ресурсу.

DELETE

Видаляє зазначений ресурс.

TRACE

Повертає отриманий запит так, що клієнт може побачити, що проміжні сервера додають або змінюють в запиті.

LINK

Встановлює зв'язок зазначеного ресурсу з іншими.

UNLINK

Прибирає зв'язок зазначеного ресурсу з іншими.

Кожен сервер зобов'язаний підтримувати як мінімум методи GET і HEAD. Якщо сервер не розпізнав вказаний клієнтом метод, то він повинен повернути статус 501 (Not Implemented). Якщо серверу метод відомий, але він не застосуємо до конкретного ресурсу, то повертається повідомлення з кодом 405 (Method Not Allowed). В обох випадках сервера слід включити в повідомлення відповіді заголовок Allow зі списком підтримуваних методів.

Найбільш затребуваними є методи GET і POST - на людино-орієнтованих ресурсах, POST - роботами пошукових машин і оффлайн-браузерами.

Примітка

Проксі-сервер

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

коди стану

Код стану інформує клієнта про результати виконання запиту і визначає його подальшу поведінку. Набір кодів стану є стандартом, і всі вони описані у відповідних документах RFC.

Кожен код представляється цілим тризначним числом. Перша цифра вказує на клас стану, наступні - порядковий номер стану (рис 1.). За кодом відповіді зазвичай слідує короткий опис англійською мовою.

Мал. 1. Структура коду стану HTTP

Введення нових кодів повинне проводитися тільки після узгодження з IETF. Клієнт може не знати всі коди стану, але він зобов'язаний відреагувати відповідно до класу коду.

Застосовувані в даний час класи кодів стану і деякі приклади відповідей сервера наведені в табл. 2.

Таблиця 2. Коди стану протоколу HTTP

Клас кодів Короткий опис 1xx Informational (Інформаційний)

У цей клас виділені коди, що інформують про процес передачі. У HTTP / 1.0 повідомлення з такими кодами повинні ігноруватися. У HTTP / 1.1 клієнт повинен бути готовий прийняти цей клас повідомлень як звичайний відповідь, але нічого відправляти сервера не потрібно. Самі повідомлення від сервера містять тільки стартову рядок відповіді і, якщо потрібно, кілька специфічних для відповіді полів заголовка. Проксі-сервера подібні повідомлення повинні відправляти далі від сервера до клієнта.

Приклади відповідей сервера:

100 Continue (Продовжувати) 101 Switching Protocols (Перемикання протоколів) 102 Processing (Йде обробка) 2xx Success (Успішно)

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

Приклади відповідей сервера:

200 OK (Успішно). 201 Created (Створено) 202 Accepted (Прийнято) 204 No Content (Немає вмісту) 206 Partial Content (Часткове вміст) 3xx Redirection (Перенаправлення)

Коди статусу класу 3xx повідомляють клієнту, що для успішного виконання операції потрібно провести наступний запит до іншого URI. У більшості випадків нова адреса вказується в полі Location заголовка. Клієнт в цьому випадку повинен, як правило, зробити автоматичний перехід (жарг. «Редирект»).

Зверніть увагу, що при зверненні до наступного ресурсу можна отримати відповідь з цього ж класу кодів. Може вийти навіть довгий ланцюжок з перенаправлень, які, якщо будуть проводитися автоматично, створять надмірне навантаження на устаткування. Тому розробники протоколу HTTP настійно рекомендують після другого поспіль подібної відповіді обов'язково запитувати підтвердження на перенаправлення у користувача (раніше рекомендувалося після 5-го). За цим стежити зобов'язаний клієнт, так як поточний сервер може перенаправити клієнта на ресурс іншого сервера. Клієнт також повинен запобігти потраплянню в кругові перенаправлення.

Приклади відповідей сервера:

300 Multiple Choices (Множинний вибір) 301 Moved Permanently (Переміщено назавжди) 304 Not Modified (Не змінювалося) 4xx Client Error (Помилка клієнта)

Клас кодів 4xx призначений для вказівки помилок з боку клієнта. При використанні всіх методів, крім HEAD, сервер повинен повернути в тексті листа гіпертекстове пояснення для користувача.

Приклади відповідей сервера:

401 Unauthorized (неавторизованого) 402 Payment Required (Потрібно оплата) 403 Forbidden (Заборонено) 404 Not Found (Не знайдено) 405 Method Not Allowed (Метод не підтримується) 406 Not Acceptable (Не прийнятно) 407 Proxy Authentication Required (Потрібно аутентифікація проксі) 5xx Server Error (Помилка сервера)

Коди 5xx виділені під випадки невдалого виконання операції з вини сервера. Для всіх ситуацій, крім використання методу HEAD, сервер повинен включати в тіло повідомлення пояснення, яке клієнт відобразить користувачеві.

Приклади відповідей сервера:

500 Internal Server Error (Внутрішня помилка сервера) 502 Bad Gateway (Поганий шлюз) 503 Service Unavailable (Сервіс недоступний) 504 Gateway Timeout (Шлюз не відповідає)

заголовки HTTP

Тема HTTP (HTTP Header) - це рядок в HTTP-повідомленні, що містить розділену двокрапкою пару виду «параметр-значення». Формат заголовка відповідає загальному формату заголовків текстових мережевих повідомлень ARPA (RFC 822). Як правило, браузер і веб-сервер включають в повідомлення більш ніж по одному заголовку. Заголовки повинні відправлятися раніше тіла повідомлення і відділятися від нього хоча б одним порожнім рядком (CRLF).

Назва параметра має складатися мінімум з одного друкованого символу (ASCII-коди від 33 до 126). Після назви відразу повинен слідувати символ двокрапки. Значення може містити будь-які символи ASCII, крім перекладу рядки (CR, код 10) і повернення каретки (LF, код 13).

Пробільні символи на початку і кінці значення обрізаються. Послідовність декількох пробільних символів всередині значення може сприйматися як один пробіл. Літери в назві і значенні не має значення (якщо інше не передбачено форматом поля).

Приклад заголовків відповіді сервера:

Server: Apache / 2.2.3 (CentOS) Last-Modified: Wed, 09 Feb 2011 17: 13: 15 GMT Content-Type: text / html; charset = UTF-8 Accept-Ranges: bytes Date: Thu, 03 Mar 2011 04: 04: 36 GMT Content-Length: 2945 Age: 51 X-Cache: HIT from proxy.omgtu Via: 1 .0 proxy.omgtu (squid /3.1.8) Connection: keep-alive 200 OK

Всі HTTP-заголовки поділяються на чотири основні групи:

1. General Headers (Основні заголовки) - повинні включатися в будь-яке повідомлення клієнта і сервера.
2. Request Headers (Заголовки запиту) - використовуються тільки в запитах клієнта.
3. Response Headers (Заголовки відповіді) - присутні тільки у відповідях сервера.
4. Entity Headers (Заголовки суті) - супроводжують кожну сутність повідомлення.

Сутності (entity, в перекладах також зустрічається назва "об'єкт") - це корисна інформація, передана в запиті або відповіді. Сутність складається з метаінформації (заголовки) і безпосередньо вмісту (тіло повідомлення).

В окремий клас заголовки суті виділені, щоб не плутати їх з заголовками запиту або заголовками відповіді при передачі множинного вмісту (multipart / * ). Заголовки запиту і відповіді, як і основні заголовки, описують все повідомлення в цілому і розміщуються тільки в початковому блоці заголовків, в той час як заголовки суті характеризують вміст кожної частини окремо, розташовуючись безпосередньо перед її тілом.

У таблиці 3 наведено короткий опис деяких HTTP-заголовків.

Таблиця 3. Заголовки HTTP

Тема Група Короткий опис Allow Entity Список методів, які можна застосувати до запитуваного ресурсу. Content-Encoding Entity Застосовується при необхідності перекодування вмісту (наприклад, gzip / deflated). Content-Language Entity Локалізація вмісту (мова (і)) Content-Length Entity Розмір тексту повідомлення (в октетах) Content-Range Entity Діапазон (використовується для підтримки багатопотокового завантаження або дозавантаження) Content-Type Entity Вказує тип вмісту (mime-type, наприклад text / html) .Часто включає вказівку на таблицю символів локалі (charset) Expires Entity Дата / час, після якої ресурс вважається застарілим. Використовується проксі-серверами Last-Modified Entity Дата / час останньої модифікації суті Cache-Control General Визначає директиви управління механізмами кешування. Для проксі-серверів. Connection General задати значення для, необхідні для конкретного з'єднання. Date General Дата і час формування повідомлення Pragma General Використовується для спеціальних вказівок, які можуть (опціонально) застосовується до будь-якого одержувачу по всьому ланцюжку запитів / відповідей (наприклад, pragma: no-cache). Transfer-Encoding General Задає тип перетворення, що застосовується до тіла повідомлення. На відміну від Content-Encoding цей заголовок поширюється на всі повідомлення, а не тільки на сутність. Via General Використовується шлюзами і проксі для відображення проміжних протоколів і вузлів між клієнтом і веб-сервером. Warning General Додаткова інформація про поточний статус, яка не може бути представлена ​​в повідомленні. Accept Request Визначає застосовні типи даних, очікуваних у відповіді. Accept-Charset Request Визначає кодування символів (charset) для даних, очікуваних у відповіді. Accept-Encoding Request Визначає застосовні формати кодування / декодування вмісту (напр, gzip) Accept-Language Request Застосовуються мови. Використовується для узгодження передачі. Authorization Request Облікові дані клієнта, що запитує ресурс. From Request Електронна адреса відправника Host Request Ім'я / мережеву адресу [і порт] сервера. Якщо порт не вказаний, використовується 80. If-Modified-Since Request Використовується для виконання умовних методів (якщо-Змінився ...). Якщо запитуваний ресурс змінився, то він передається з сервера, інакше - з кешу. Max-Forwards Request Являє механиз обмеження кількості шлюзів і проксі при використанні методів TRACE і OPTIONS. Proxy-Authorization Request Використовується при запитах, що проходять через проксі, що вимагають авторизації Referer Request Адреса, з якого виконується запит. Цей заголовок відсутній, якщо перехід виконується з адресного рядка або, наприклад, за посиланням з js-скрипта. User-Agent Request Інформація про призначеному для користувача агента (клієнта) Location Response Адреса перенаправлення Proxy-Authenticate Response Повідомлення про статус з кодом 407. Server Response Інформація про програмне забезпечення сервера, що відповідає на запит (це може бути як веб- так і проксі-сервер) .

У лістингу 1 наведено фрагмент дампа заголовків при підключенні до сервера http://example.org

Лістинг 1. Заголовки HTTP

http://www.example.org/ GET http://www.example.org/ HTTP / 1.1 Host: www.example.org User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9.2.13) Gecko / 20101203 SUSE / 3.6.13-0.2.1 Firefox / 3.6.13 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Language: ru-ru, ru; q = 0.8, en-us; q = 0.5, en; q = 0.3 Accept-Encoding: gzip, deflate Accept-Charset: windows-1251, utf-8; q = 0.7, *; q = 0.7 Keep-Alive: 115 Proxy-Connection: keep-alive HTTP / 1.0 302 Moved Temporarily Date: Thu, 03 Mar 2011 06: 48: 28 GMT Location: http://www.iana.org/domains/example/ Server: BigIP Content-Length: 0 X-Cache: MISS from proxy.omgtu Via: 1 .0 proxy.omgtu (squid / 3.1.8) Connection: keep-alive ------------- --------------------------------------------- http: // www .iana.org / domains / example / GET http://www.iana.org/domains/example/ HTTP / 1.1 Host: www.iana.org User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru ; rv: 1.9.2.13) Gecko / 20101203 SUSE / 3.6.13-0.2.1 Firefox / 3.6.13 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Language: ru-ru, ru; q = 0.8, en-us; q = 0.5, en; q = 0.3 Accept-Encoding: gzip, deflate Accept-Charset: windows-1251, utf-8; q = 0.7, *; q = 0.7 Keep-Alive: 115 Proxy-Connection: keep-alive HTTP / 1.0 200 OK Server: Apache / 2.2.3 (CentOS) Last-Modified: Wed, 09 Feb 2011 17: 13: 15 GMT Content-Type: text / html; charset = UTF-8 Accept-Ranges: bytes Date: Thu, 03 Mar 2011 04: 04: 36 GMT Content-Length: 2945 Age: 9858 X-Cache: HIT from proxy.omgtu Via: 1 .0 proxy.omgtu (squid /3.1.8) Connection: keep-alive ....

Кілька корисних прикладів php-скриптів, оброблювальних HTTP-заголовки, наведені в статті «Використання файлу .htaccess» (редирект, відправка коду помилки, установка last-modified і т.п.).

тіло повідомлення

Тіло HTTP повідомлення (message-body), якщо воно присутнє, використовується для передачі суті, пов'язаної із запитом або відповіддю. Тіло повідомлення (message-body) відрізняється від тіла сутності (entity-body) тільки в тому випадку, коли при передачі застосовується кодування, вказане в заголовку Transfer-Encoding. В інших випадках тіло повідомлення ідентично тілу суті.

Тема Transfer-Encoding повинен відправлятися для вказівки будь-якого кодування передачі, застосованого додатком з метою гарантування безпечної та правильної передачі повідомлення. Transfer-Encoding - це властивість повідомлення, а не сутності, і воно може бути додано або видалено будь-яким додатком в ланцюжку запитів / відповідей.

Присутність тіла повідомлення в запиті зазначається додаванням до заголовків запиту поля заголовка Content-Length або Transfer-Encoding. Тіло повідомлення (message-body) може бути додано в запит тільки коли метод запиту допускає тіло об'єкта (entity-body).

Всі відповіді містять тіло повідомлення, можливо нульової довжини, крім відповідей на запит методом HEAD і відповідей з кодами статусу 1xx (Інформаційні), 204 (Ні вмісту, No Content), і 304 (Не модифікований, Not Modified).

контрольні питання

1. В якому випадку клієнт отримає від сервера відповідь з кодом 418?