Протокол передачі гіпертексту – HTTP/1.1, HTML, XML, DHTML, Інтернет-технології, статті

Переклад:Олексій Симонов

 Протокол передачі гіпертексту – HTTP/1.1
Про переведення.
Саме тут представлений переклад документа RFC 2068 на російську мову. При перекладі я користувався особистим досвідом і здоровим глуздом, тому в деяких місцях читач, знайомий з оригіналом, може помітити несуттєві відмінності. Я з усіх сил намагався надати легкий для читання вид, але в деяких місцях ви зустрінете пропозиції, написані “Криво” (це пов’язано або з “технічністю” тексту, або з моїми проблемами в російській мові). Переконливе прохання : Якщо зустрінете друкарські помилки, помилки, або у вас з’являться пропозиції по поліпшення окремих фраз або цілих фрагментів – повідомте мені по адресою Leshik@omsk.com.
Я віддаю собі звіт в тому, що деякі терміни, можливо, переведені некоректно. При сумнівах я додавав англійські терміни в круглих дужках. Наприклад: запит (request).
У змісті вказані сторінки англійського оригіналу.
Цим перекладом я не переслідував комерційних цілей, тому я не несу відповідальності за невідповідність російського перекладу англійському оригіналу. Якщо Ви бажаєте отримати адекватний переклад цього документа (чи якогось іншого з комп’ютерної тематики), то я можу його переробити відповідно до Ваших вимог за певну плату (це пов’язано з моїм важким фінансовим становищем як студента).
Олексій Симонов.
Статус даного документа.
Цей документ визначає протокол доріжки стандартів Інтернету (Internet standards track protocol) для сімейства Інтернету, і призначений для обговорення і пропозицій з удосконалення. Будь ласка зверніться до поточного виданню “Офіційних стандартів протоколів Інтернет “(STD 1) для з’ясування стану стандартизації і статусу цього протоколу. Поширення даного документа необмежена.
Реферат.
Протокол передачі гіпертексту (HTTP) – протокол прикладного рівня для розподілених, спільних, многосредность інформаційних систем. Це загальний, платформно-незалежний, об’єктно-орієнтована протокол, який може використовуватися в багатьох задачах, таких як сервера імен і розподілені системи керування об’єктами, за допомогою розширення методів запиту.
Можливість HTTP – це друк та обговорення представлення даних, дозволяє будувати системи незалежно від переданих даних.
HTTP використовується в World Wide Web (WWW) починаючи з 1990 року. Ця специфікація визначає протокол, який згадується як “HTTP/1.1”.
Зміст.
1 Введення ………………………………………… 7 1.1 Мета ………………………………………… .7 1.2 Вимоги ……………………………………. 7 1.3 Термінологія ………………………………….. 8 1.4 Загальний опис ……………………………….. 11 2 Письмові угоди та узагальнена граматика ………. 13 2.1 Збільшена нормальний запис Бекуса-Наура (BNF) …. 13 2.2 Основні правила ……………………………… 15 3 Параметри протоколу ……………………………… 17 3.1 Версія HTTP ………………………………….. 17 3.2 Універсальні Ідентифікатори Ресурсів (URI) ……… 18 3.2.1 Загальний синтаксис ……………………………. 18
3.2.2 HTTP URL …………………………………..19 3.2.3 Порівняння URI ……………………………… 20 3.3 Формати дати / часу ………………………….. 21 3.3.1 Повна дата ……………………………….. 21 3.3.2 Різниця секунд (delta seconds) ……………… 22 3.4 Кодові таблиці (character sets) ……………….. 22 3.5 Кодування вмісту (content codings) ……….. 23 3.6 Кодування передачі (transfer codings) …………. 24 3.7 Медіа типи (Media Types) ………………………. 25 3.7.1 Канонізація і зумовлені значення типу
text ………………………………………26 3.7.2 Типи Multipart …………………………….. 27 3.8 Лексеми програм (Product Tokens) ………………. 28 3.9 Якісні значення (Quality Values) ………….. 28 3.10 Мітки мов (Language Tags) ………………….. 28 3.11 Мітки об’єктів (Entity Tags) ………………….. 29 3.12 одиниці виміру діапазонів (Range Units) ……… 30 4 HTTP повідомлення (HTTP Message) …………………….. 30 4.1 Типи повідомлень ……………………………….. 30 4.2 Заголовки повідомлень …………………………… 31 4.3 Тіло Cообщения ……………………………….. 32 4.4 Довжина повідомлення ………………………………. 32 4.5 Загальні поля заголовка ………………………….. 34 5 Запит (Request) ………………………………… 34 5.1 Рядок запиту (Request-Line) ………………….. 34 5.1.1 Метод (Method) …………………………….. 35 5.1.2 Запитуваний URI (Request-URI) ……………… 35 5.2 Ресурс, ідентифікований запитом ………………. 37 5.3 Поля заголовка запиту ………………………… 37 6 Відповідь (Response) ………………………………… 38 6.1 Рядок стану (Status-Line) …………………. 38 6.1.1 Код стану і пояснює фраза …………….. 39 6.2 Поля заголовка відповіді …………………………. 41 7 Об’єкт (Entity) …………………………………. 41 7.1 Поля заголовка об’єкта ………………………… 41 7.2 Тіло об’єкта …………………………………. 42 7.2.1 Тип (Type) ………………………………… 42 7.2.2 Довжина (Length) …………………………….. 43 8 Сполуки (Connections) …………………………. 43 8.1 Постійні з’єднання (Persistent Connections) …… 43 8.1.1 Мета ……………………………………… 43 8.1.2 Загальний опис …………………………….. 44 8.1.3 Проксі-сервера (Proxy Servers) ………………. 45 8.1.4 Практичні Угоди про використання …………………….. 45 8.2 Вимоги до передачі повідомлень ………………… 46 9 Визначення методів (Method Definitions) …………… 48 ? 9.1 Безпечні і Idempotent Методи …………………. 48 9.1.1 Безпечні методи ………………………….. 48 ? 9.1.2 Idempotent методи (Idempotent Methods) ……….. 49
9.2 OPTIONS ………………………………………49
9.3 GET ………………………………………….50
9.4 HEAD …………………………………………50
9.5 POST …………………………………………51
9.6 PUT ………………………………………….52
9.7 DELETE ……………………………………….53
9.8 TRACE ………………………………………..53 10 Опис кодів стану ………………………… 53 10.1 1xx – Інформаційні коди …………………….. 54 10.1.1 100 Продовжувати, Continue …………………… 54 10.1.2 101 Перемикання протоколів, Switching
Protocols ……………………………..54 10.2 2xx – Успішні коди ………………………….. 54 10.2.1 200 ОК …………………………………… 54 10.2.2 201 Створений, Created ……………………….. 55 10.2.3 202 Прийнято, Accepted ……………………… 55 10.2.4 203 Чи не авторська інформація, Non-Authoritative
Information ……………………………55 10.2.5 204 Немає вмісту, No Content …………….. 55 10.2.6 205 Скинути вміст, Reset Content ………. 56 10.2.7 206 Часткове вміст, Partial Content ……. 56 10.3 3xx – Коди перенаправлення ……………………. 56 10.3.1 300 Множинний вибір, Multiple Choices ……. 57 10.3.2 301 Постійно перенесений, Moved Permanently …… 57 10.3.3 302 Тимчасово переміщено, Moved Temporarily ……. 58 10.3.4 303 Дивитися інший, See Other ……………… 58 10.3.5 304 Чи не модифікований, Not Modified ………….. 58 10.3.6 305 Використовуйте проксі-сервер, Use Proxy …….. 59 10.4 4xx – Коди помилок клієнта …………………….. 59 10.4.1 400 Зіпсований Запит, Bad Request …………. 60 10.4.2 401 Несанкціоновано, Unauthorized ………… 60 10.4.3 402 Требуется оплата, Payment Required ………. 60 10.4.4 403 Заборонено, Forbidden …………………… 60 10.4.5 404 Чи не знайдений, Not Found …………………… 60 10.4.6 405 Метод не дозволений, Method Not Allowed ……. 61 10.4.7 406 Чи не прийнятний, Not Acceptable …………….. 61 10.4.8 407 Требуется встановлення автентичності через проксі-сервер, Proxy Authentication
Required ………………………………61 10.4.9 408 закінчено час очікування запиту, Request
Timeout ……………………………….62 10.4.10 409 Конфлікт, Conflict ……………………. 62 10.4.11 410 Вилучений, Gone …………………………. 62 10.4.12 411 Требуется довжина, Length Required ……….. 63 10.4.13 412 Передумови невірно, Precondition Failed … 63 10.4.14 413 Об’єкт запиту занадто великий, Request
Entity Too Large ………………………63 10.4.15 414 URI запиту занадто довгий, Request-URI
Too Long ……………………………..63 10.4.16 415 Непідтримуваний медіа тип, Unsupported
Media Type ……………………………63 10.5 5xx – Коди помилок сервера …………………….. 64 10.5.1 500 Внутрішня помилка сервера, Internal Server
Error …………………………………64 10.5.2 501 Чи не реалізовано, Not Implemented …………. 64 10.5.3 502 Помилка шлюзу, Bad Gateway ………………. 64 10.5.4 503 Сервіс недоступний, Service Unavailable …… 64 10.5.5 504 закінчено час очікування від шлюзу, Gateway
Timeout ……………………………….64 10.5.6 505 Чи не підтримувана версія HTTP, HTTP Version
Not Supported ………………………….65 11 Встановлення автентичності доступу (Access
Authentication) …………………………………65 11.1 Базова схема встановлення автентичності (Basic
Authentication Scheme) ………………………..66 11.2 Оглядова схема встановлення автентичності (Digest
Authentication Scheme) ………………………..67 12 Обговорення вмісту (Content Negotiation) ………. 67 12.1 Кероване сервером обговорення ……………….. 68 12.2 Кероване агентом обговорення ………………… 69 12.3 Прозоре обговорення ………………………… 70 13 Кешування в HTTP ……………………………… 70 13.1.1 Правильність кешування …………………… 72 13.1.2 Попередження ……………………………. 73 13.1.3 Механізми управління кешем …………………. 74 13.1.4 Явні попередження User Agent …………….. 74 13.1.5 Винятки з правил і попереджень ……….. 75 13.1.6 Контролліруемое клієнтом поведінка ………….. 75 13.2 Модель устаревания …………………………… 75 13.2.1 Старіння, определеяется сервером …………. 75 13.2.2 Евристичне старіння ………………….. 76 13.2.3 Обчислення віку ……………………….. 77 13.2.4 Обчислення старіння …………………….. 79 13.2.5 Значення однозначного устаревания …………… 80
13.2.6 Disambiguating Multiple Responses ……………80 13.3 Модель порівняння (validation model) ……………. 81 13.3.1 Дати останньої зміни (Last-modified Dates) .. 82 13.3.2 Об’єктні позначки порівняння кеша ……………. 82 13.3.3 Слабке і сильне порівняння …………………. 82 13.3.4 Правила коли використовувати об’єктні позначки (Entity Tags) і дати останньої зміни (Last-
modified Dates)…………………………………..85 13.3.5 непроверяемие умови ……………………… 86 13.4 Cachability відповіді …………………………… 86 13.5 Побудова відповідей з кешей …………………… 87 13.5.1 Наскрізні (End-to-end) і проміжні (Hop-by-hop) заголовки ………………………………………. 88 13.5.2 немодіфіціруемих заголовки …………………. 88 13.5.3 Об’єднання заголовків …………………….. 89 13.5.4 об’едіннених діапазонів байтів ……………… 90 13.6 Кешування переговорних відповідей (Negotiated
Responses)………………………………………..90 13.7 Загальнодоступні і необщедоступние кеші …………… 91 13.8 Поведінка кеша при помилкових або незавершених відповідях …………………………………………. 91 13.9 Побічні ефекти GET і HEAD …………………… 92 13.10 Помилки після модифікацій або стирання …………. 92
13.11 Write-Through Mandatory ………………………93 13.12 Заміна кешу ………………………………… 93 13.13 Списки history ……………………………… 93 14 Визначення полів заголовка ……………………… 94
14.1 Accept ………………………………………95
14.2 Accept-Charset ……………………………….97
14.3 Accept-Encoding ………………………………97
14.4 Accept-Language ………………………………98
14.5 Accept-Ranges ………………………………..99
14.6 Age …………………………………………99
14.7 Allow ………………………………………100
14.8 Authorization ……………………………….100
14.9 Cache-Control ……………………………….101 14.9.1 Що кешируємой (Cachable) ………………….. 103 14.9.2 Що може бути збережено кешем …………….. 103 14.9.3 Модифікації основного механізму старіння …. 104 14.9.4 повторної перевірки правильності кеша і засоби управління перезавантаженням ………………………… 105 14.9.5 Директива No-Transform ……………………. 107 14.9.6 Розширення засобів керування кешем ………… 108
14.10 Connection …………………………………109
14.11 Content-Base ……………………………….109
14.12 Content-Encoding ……………………………110
14.13 Content-Language ……………………………110
14.14 Content-Length ……………………………..111
14.15 Content-Location ……………………………112
14.16 Content-MD5 ………………………………..113
14.17 Content-Range ………………………………114
14.18 Content-Type ……………………………….116
14.19 Date ………………………………………116
14.20 ETag ………………………………………117
14.21 Expires ……………………………………117
14.22 From ………………………………………118
14.23 Host ………………………………………119
14.24 If-Modified-Since …………………………..119
14.25 If-Match …………………………………..121
14.26 If-None-Match ………………………………122
14.27 If-Range …………………………………..123
14.28 If-Unmodified-Since …………………………124
14.29 Last-Modified ………………………………124
14.30 Location …………………………………..125
14.31 Max-Forwards ……………………………….125
14.32 Pragma …………………………………….126
14.33 Proxy-Authenticate ………………………….127
14.34 Proxy-Authorization …………………………127
14.35 Public …………………………………….127
14.36 Range ……………………………………..128 14.36.1 Діапазони байт (byte ranges) ……………… 128 14.36.2 Запити діапазонів (Range Retrieval
Requests) ………………………………………130
14.37 Referer ……………………………………131
14.38 Retry-After ………………………………..131
14.39 Server …………………………………….132
14.40 Transfer-Encoding …………………………..132
14.41 Upgrade ……………………………………132
14.42 User-Agent …………………………………134
14.43 Vary ………………………………………134
14.44 Via ……………………………………….135
14.45 Warning ……………………………………137
14.46 WWW-Authenticate ……………………………139 15 Положення про захист …………………………….. 139 15.1 Встановлення справжності клієнтів …………….. 139 15.2 Пропозиція обрати схему встановлення справжності ……………………………………… 140 15.3 Неправильне поводження з інформацією файлу реєстрації сервера (Log) …………………………. 141 15.4 Передача чутливої ​​(sensitive) інформації …. 141 15.5 Атаки, засновані іменах файлів і шляхів ………… 142 15.6 Персональна інформація ……………………… 143 15.7 Проблеми таємності, пов’язані з Accept заголовками …………………………………….. 143 15.8 Підміна DNS-адрес (DNS Spoofing) …………….. 144 15.9 Місцезнаходження заголовків і Spoofing ……………. 144 16 Підтвердження …………………………………. 144 17 Посилання ……………………………………….. 146 18 Адреси авторів ………………………………… 149 19 Додатка ……………………………………. 150 19.1 Медіа тип Інтернет message / http ………………. 150 19.2 Медіа тип Інтернет multipart / byteranges ……….. 150 19.3 Допустимі програми ……………………….. 151 19.4 Відмінності між HTTP об’єктами і MIME об’єктами …. 152 19.4.1 Перетворення до канонічної формі ………… 152 19.4.2 Перетворення форматів дат ……………….. 153 19.4.3 Введення Content-Encoding …………………. 153 19.4.4 Ніякого Content-Transfer-Encoding …………. 153 19.4.5 Поля HTTP заголовка в Multipart Body-Parts ….. 153 19.4.6 Введення Transfer-Encoding ………………… 154 19.4.7 Версія MIME ……………………………… 154 19.5 Зміни після HTTP/1.0 …………………….. 154 19.5.1 Зміни упрощаущіе багато-homed сервера і зберігають IP адреси …………………………… 155 19.6 Додаткові можливості …………………… 156 19.6.1 Додаткові методи запитів …………….. 156 19.6.2 Додаткові визначення полів заголовка ….. 156 19.7 Сумісність з попередніми версіями ………….. 160 19.7.1 Сумісність з постійними сполуками, обумовленими HTTP/1.0 …………………………. 161

1 Введення.


1.1 Мета.


Протокол передачі гіпертексту (HTTP) – протокол прикладного рівня для розподілених, спільних, многосредность інформаційних систем. HTTP використовується в World Wide Web (WWW) починаючи з 1990 року. Першою версією HTTP, відомої як HTTP/0.9, був простий протокол для передачі необроблених даних через Інтернет. HTTP/1.0, як визначено в RFC 1945 [6], був поліпшенням цього протоколу, дозволяючи повідомленнями мати MIME-подібний формат, що містить метаінформацію про переданих даних і мав модифіковану семантику запитів / відповідей. Однак, HTTP/1.0 недостатньо добре враховував особливості роботи з ієрархічними проксі-серверами (hierarchical proxies), кешуванням, постійними сполуками, і віртуальними хостами (virtual hosts). Крім того, швидке збільшення не повністю сумісних програм, які називають той протокол, який вони використовували “HTTP/1.0”, зажадало введення версії протоколу, в якої були б закладені можливості, що дозволяють додаткам визначати істинні можливості один одного.
Ця специфікація визначає протокол “HTTP/1.1”. Цей протокол містить більш суворі вимоги, ніж HTTP/1.0, що гарантують надійну реалізацію можливостей.
Практично інформаційні системи вимагають більшої функціональності, ніж просто завантаження інформації, включаючи пошук, модифікацію при допомогою зовнішнього інтерфейсу, і анотацію (annotation). HTTP надає відкритий набір методів, які вказують мету запиту. Вони засновані на дисципліні посилання, забезпеченої Універсальним Ідентифікатором Ресурсу (URI) [3] [20], як розташування (URL) [4] або ім’я (URN), для ідентифікації ресурсу, до якого цей метод застосовується. Повідомлення передаються в форматі, подібному використовуваному електронною поштою, як визначено багатоцільові розширення Електронної Пошти (MIME).
HTTP також використовується як узагальнений протокол зв’язку між агентами користувачів і проксі-серверамі/шлюзамі (proxies / gateways) або іншими сервісами Інтернету, включаючи такі, як SMTP [16], NNTP [13], FTP [18], Gopher [2], і WAIS [10]. Таким чином, HTTP закладає основи многосредность (hypermedia) доступу до ресурсів для різноманітних додатків.

1.2 Вимоги.


Ця специфікація використовує ті ж самі слова для визначення вимог до реалізації протоколу, що і RFC 1123 [8]. Ці слова такі:
ТРЕБА, МАЄ (MUST) Застосовується для вказівки, що дана вимога специфікації необхідно забезпечити в будь-якому випадку.
РЕКОМЕНДУЄТЬСЯ, СЛІД (SHOULD) Використовується для вказівки, що дана вимога специфікації повинно бути забезпечено, якщо цьому не перешкоджають серйозні причини.
МОЖЛИВО, МОЖЕ (MAY) Використовується для вказівки, що дана вимога специфікації є опціональним і може бути або реалізовано, або ні – за потребою.
Реалізація вважається несумісною, якщо порушено хоча б одне НЕОБХІДНИХ вимог специфікації протоколу. Реалізація, задовольняє всім необхідним і РЕКОМЕНДОВАНІ тредованіям називається повністю сумісної, а задовольняє всім необхідним, але не всім Рекомендовані вимоги називається умовно сумісною.

1.3 Термінологія.


Ця специфікація використовує ряд термінів для опису ролі учасників, деяких об’єктів, і HTTP зв’язку.
З’єднання (connection) Віртуальний канал транспортом рівня, встановлений між двома програмами з метою зв’язку.
Повідомлення (message) Основний модуль HTTP зв’язку, що складається з структурної послідовності октетів, відповідних синтаксису, визначеному в розділі 4 і переданих по з’єднанню.
Запит (request) Будь HTTP повідомлення, що містить запит, який визначається в розділі 5.
Відповідь (response) Будь HTTP повідомлення, що містить відповідь, який визначається в розділі 5.
Ресурс (resource) Мережевий об’єкт даних або сервіс, який може бути ідентифікований URI, определеляемим в розділі 3.2. Ресурси можуть бути доступні в декількох виставах (наприклад на декількох мовах, в різних форматах даних, мати різний розмір, мати різну роздільну здатність) або відрізнятися з інших параметрам.
Об’єкт (entity) Інформація, передана в якості корисного навантаження запиту або відповіді. Об’єкт складається з метаінформації у формі полів заголовка об’єкта та змісту у формі тіла об’єкта, як описано в розділі
7.
Подання (representation) Об’єкт включений у відповідь, і підкоряється обговорення вмісту (Content Negotiation), що описано в розділі 12. Може існувати кілька подань, пов’язаних зі специфічними станами відповіді.
Обговорення вмісту (content negotiation) Механізм для вибору відповідного подання під час обслуговування запиту, як описано в розділі 12. Представлення об’єктів в будь-якій відповіді може бути обговорено (включаючи помилкові відповіді).
Варіант (variant) Ресурс може мати одне, або декілька уявлень, пов’язаних з ним в даний момент. Кожне з цих уявлень називається “Варіант”. Використання терміну “варіант” не обов’язково увазі, що ресурс підпорядкований обговоренню вмісту.
Клієнт (client) Програма, яка встановлює з’єднання з метою посилки запитів.
Агент користувача (user agent) Клієнт, який ініціює запит. Як правило браузери, редактори, роботи (spiders), або інші інструментальні кошти користувача.
Сервер (server) Додаток, який слухає з’єднання, приймає запити на обслуговування і посилає відповіді. Будь-яка така програма здатна бути як клієнтом, так і сервером; наше використання даного терміна відноситься скоріше до ролі, яку програма виконує, створюючи специфічні сполуки, ніж до можливостей програми взагалі. Аналогічно, будь-який сервер може діяти як первинний сервер, проксі-сервер, шлюз, або тунель (tunnel), змінюючи поведінку, грунтуючись на характері кожного запиту.
Початковий сервер (origin server) Сервер, на якому даний ресурс постійно перебуває або має бути створений.
Проксі-сервер (proxy) Програма-посередник, яка діє і як сервер, і як клієнт з метою створення запитів від імені інших клієнтів. Запити обслуговуються проксі-сервером, або передаються їм, можливо зі змінами. Проксі-сервер повинен задовольняти вимогам клієнта і сервера, відповідно до цієї специфікації.
Шлюз (gateway) Сервер, який діє як посередник для деякого іншого сервера. На відміну від проксі-сервера, шлюз отримує запити в якості початкового сервера для запитаного ресурсу; клієнт запиту може не знати, що він з’єднується з шлюзом.
Тунель (tunnel) Програма-посередник, яка підтримує з’єднання. Один раз створений, тунель не розглядається як частина HTTP зв’язку, хоча тунель, можливо, був инициализирован запитом HTTP. Тунель припиняє існувати, коли обидва кінці з’єднання закриваються.
Кеш (cache) Локальна пам’ять, в якій програма зберігає повідомлення відповідей, і в якій розташовується підсистема, що управляє зберіганням, пошуком і стиранням повідомлень. Кеш зберігає відповіді, які можуть бути збережені, щоб зменшити час відповіді або пересилання мережі (трафік) при майбутніх еквівалентних запитах. Будь-який клієнт або сервер може мати кеш, але кеш не може використовуватися сервером, який діє як тунель.
Кешована (cachable) Відповідь є Кешована, якщо кешу дозволено зберегти копію відповідного повідомлення для використання при відповіді на наступні запити. Правила для визначення кешируємой HTTP відповідей визначені в розділі 13. Навіть якщо ресурс кешіруем, можуть існувати додаткові обмеження на використання кешем збереженої копії для подібного запиту.
Безпосередній (first-hand) Відповідь вважається безпосереднім, якщо він приходить безпосередньо від первинного сервера без непотрібної затримки, можливо через один або кілька проксі-серверів. Відповідь також є безпосереднім, якщо його правильність щойно була перевірена безпосередньо початковим сервером.
Точний час старіння (explicit expiration time) Час, визначений первісним сервером і показує кешу, коли об’єкт більше не може бути повернутий кешем клієнту без додаткової перевірки правильності.
Евристичне час старіння (heuristic expiration time) Час старіння, призначена кешем, якщо не вказано точне час старіння.
Вік (age) Вік відповіді – час, що минув з моменту відсилання, або успішної перевірки відповіді первісним сервером.
Час життя (freshness lifetime) Відрізок часу між породженням відповіді і часом старіння.
Свіжий (fresh) Відповідь вважається свіжим, якщо його вік ще не перевищив час життя.
Просроченнний (stale) Відповідь вважається простроченим, якщо його вік перевищив час життя.
Семантично прозорий (semantically transparent) Кажуть, що кеш веде себе “семантично прозорим” образом в відносно специфічного відповіді, коли використання кешу не впливає ні на клієнта запиту, ні на первинний сервер, але підвищує ефективність. Коли кеш семантично прозорий, клієнт отримує точно таку ж відповідь (за винятком проміжних (Hop-by-hop) заголовків), який отримав би, запитуючи безпосередньо первинний сервер, а не кеш.
? Покажчик правильності (validator) Елемент протоколу (наприклад, мітка об’єкта або час останньої модифікації (Last-Modified time)), який використовується, щоб з’ясувати, чи є що знаходиться в кеші копія еквівалентом об’єкта.

1.4 Загальний опис.


Протокол HTTP – це протокол запитів / відповідей. Клієнт посилає серверу запит, що містить метод запиту, URI, версію протоколу, MIME-подібне повідомлення, що містить модифікатори запиту, клієнтську інформацію, і, можливо, тіло запиту, по з’єднанню. Сервер відповідає рядком стану, що включає версію протоколу повідомлення, код успішного виконання або код помилки, MIME-подібне повідомлення, містить інформацію про сервер, метаінформацію об’єкта, і, можливо, тіло об’єкта. Зв’язок між HTTP і MIME описана в додатку
19.4.
Більшість HTTP з’єднань ініціалізується агентом користувача та складається із запиту, який потрібно застосувати до ресурсу на деякому первинному сервері. У самому простому випадку, він може бути виконаний за допомогою одиночного з’єднання (v) між агентом користувача (UA) і первісним сервером (O).
ланцюжок запитів ———————>
UA ——————-v——————- O <----------------------- Ланцюжок відповідей Більш складна ситуація виникає, коли в ланцюжку запитів / відповідей присутній один або кілька посередників. Існують три основні різновиди посередників: проксі-сервера, шлюзи, і тунелі. Проксі-сервер є агентом-посередником, який отримує запити на деякий URI в абсолютній формі, змінює все повідомлення або його частина, і відсилає змінений запит серверу, ідентифікованому URI. Шлюз - це приймає агент, діючий як би рівень вище деякого іншого сервера (ів) і, в разі необхідності, що транслює запити до протоколу основного сервера. Тунель діє як реле між двома з'єднаннями не змінюючи повідомлення; тунелі використовуються, коли зв'язок потрібно робити через посередника (наприклад Firewall), який не розуміє зміст повідомлень. ланцюжок запитів ----------------------------------->
UA —–v—– A —–v—– B —–v—– C —–v—– O <------------------------------------ Ланцюжок відповідей На останньому малюнку показані три посередника (A, B, і C) між агентом користувача і первісним сервером. Запити та відповіді передаються через чотири окремі з'єднання. Ця відмінність важливо, так як деякі опції HTTP з'єднання застосовні лише до з'єднанню з найближчим НЕ тунельним сусідом, деякі тільки до кінцевим точкам ланцюжка, а деякі до всіх з'єднань в ланцюжку. Хоча діаграма лінійна, кожен учасник може бути задіяний в кількох з'єднаннях одночасно. Наприклад, B може отримувати запити від інших клієнтів, а не тільки від A, та / або пересилати запити до серверів, відмінним від C, в той же час, коли він обробляє запит від А. Будь-яка сторона сполуки, яка не діє як тунель, може використовувати внутрішній кеш для обробки запитів. Ефект кешу полягає в тому, що ланцюжок запитів / відповідей скорочується, якщо один з учасників в ланцюжку має кешированний відповідь, що застосовується до даного запиту. Далі ілюструється ланцюжок, що виникає в Внаслідок того, що B має кешуванню копію раннього відповіді O (Отриманий позичальником через C) для запиту, і який не кешуватися ні UA, ні A. ланцюжок запитів ------->
UA —–v—– A —–v—– B – – – – – – C – – – – – – O <-------- Ланцюжок відповідей Не всі відповіді корисно кешувати, а деякі запити можуть містити модифікатори, які включають спеціальні вимоги, керують поведінкою кеша. Вимоги HTTP для поведінки кеша в відношенні Кешована відповідей визначені в розділі 13. Фактично, є широке розмаїття архітектур і конфігурацій кешей і проксі-серверів, в даний час розробляються або розгорнутих в World Wide Web; ці системи включають національні ієрархії проксі-кешей, які зберігають пропускну здатність міжокеанського каналів, системи, які поширюють у багато місць вміст кешу, організації, які поширюють підмножини Кешована даних на CD-ROM, і так далі. HTTP системи використовуються в корпоративних інтранет-мережах з високошвидкісними лініями зв'язку, і для доступу через PDA з малопотужними лініями і нестійкою зв'язку. Мета HTTP/1.1 полягає в підтримці широкого різноманіття конфігурацій, вже побудованих при введенні ранніх версій протоколу, а також у задоволенні потреб розробників web додатків, що вимагають високої надійності, за Принаймні надійних щодо індикації відмови. HTTP з'єднання зазвичай відбувається за допомогою TCP / IP з'єднань. Заданий за замовчуванням порт TCP - 80, але можуть використовуватися і інші порти. HTTP також може бути реалізований за допомогою будь-якого іншого протоколу Інтернету, або інших мереж. HTTP необхідна тільки надійна передача даних, отже може використовуватися будь-який протокол, який гарантує надійну передачу даних; відображення структури запиту і відповіді HTTP/1.1 на транспортні модулі даних розглянутого протоколу - питання, не вирішуване цієї специфікації. Більшість реалізацій HTTP/1.0 використовувало нове з'єднання для кожного обміну запитом / відповіддю. В HTTP/1.1, встановлене з'єднання може використовуватися для одного або декількох обмінів запитом / відповіддю, хоча з'єднання може бути закрито по ряду причин (дивіться розділ 8.1).

2 Письмові угоди та узагальнена граматика.


2.1 Збільшена нормальний запис Бекуса-Наура (BNF).


Усі механізми, визначені цим документом, описані як у звичайній, так і в збільшеній нормальної записи Бекуса-Наура (BNF), подібної використовуваної в RFC 822 [9]. Розробник повинен бути знайомий з такою формою записи, щоб зрозуміти цю специфікацію. Збільшена нормальна запис Бекуса-Наура включає такі конструкції:
ім’я = визначення
name = definition Ім’я правила – це просто його назву (не включає символів “<" І ">“), і відокремлюване від визначення символом рівності “=”. Пробіл важливий тільки при вирівнюванні триваючих рядків, використовуваних для вказівки визначень правил, які займають більше одного рядка. Деякі основні правила, такі як SP, LWS, HT, CRLF, DIGIT, ALPHA і т.д, представлені в верхньому регістрі. Кутові дужки використовуються у визначенні всякий раз, коли їхня присутність полегшує використання імен правил.
“Літерал”
“literal” Лапки оточують літеральний текст. Якщо не встановлено іншого, цей текст регістру незалежний.
правіло1 | правіло2
rule1 | rule2 Елементи, відокремлювані смугою (“|”) є варіантами. Наприклад, “Так | немає” приймає значення або так, або ні.
(Правіло1 правіло2)
(rule1 rule2) Елементи, включені в круглі дужки обробляються як один елемент. Таким чином, “(elem (foo | bar) elem)” допускає послідовності лексем “elem foo elem” і
“elem bar elem”.
* Правило
*rule Символ “*”, що передує елементу, вказує повторення. Повна форма – “ * element” означає мінімум , максимум входжень елемента. Значення за замовчуванням – 0 і нескінченність. Таким чином запис “* (element)” допускає будь-яке число повторень (у тому числі нуль); запис “1 * element” вимагає принаймні одне повторення; а “1 * 2element” допускає або один, або два повторення.
[Правило]
[rule] У квадратні дужки укладають опціональні елементи; “[foo bar]” еквівалентно “* 1 (foo bar)”.
N правило
N rule Точна кількість повторень: “ (element)” еквівалентно “ * (Element)”; тобто присутній точно повторів елемента. Таким чином 2DIGIT – номер з 2 цифр, а 3ALPHA – Рядок із трьох алфавітних символів.
# Правило
#rule Конструкція “#” призначена, подібно “*”, для визначення списку елементів. Повна форма – “ # element” означає мінімум , максимум входжень елемента, відокремлених однієї або кількома комами (“,”), і, можливо, лінійним пропуском (LWS). Це звичайно робить форму списків дуже простий; правило типу “(* LWS element * (* LWS”, “* LWS element))” можна представити як “1 # елемент”. Скрізь, де використовується ця конструкція, порожні елементи допускаються, але не враховуються при підрахунку поданих елементів. Тобто конструкція “(Element),, (element)” допускається, але вважаються в ній тільки два елементи. Отже там, де потрібно принаймні один елемент, повинен бути присутнім принаймні один не порожній елемент. Значення за замовчуванням – 0 і нескінченність. Таким чином запис “# (element)” допускає будь-яке число повторень (у тому числі нуль); запис “1 # element” вимагає по Принаймні одного повтору ненульового елемента; а “1 * 2element” допускає один або два повтори.
; Коментар
; comment Крапка з комою, поставлена ​​справа від тексту правила, починає коментар, який триває до кінця рядка. Це – простий спосіб включення корисних позначок паралельно специфікаціям.
маючи на увазі * LWS
implied *LWS Граматика, описана цієї специфікацією заснована на словах. За винятком випадків, в яких зазначено інше, лінійний пробіл (LWS) може бути включений між будь-якими двома суміжними словами (лексемою чи рядком цитування), і між суміжними лексемами і роздільниками (tspecials), не змінюючи інтерпретацію поля. Між будь-якими двома лексемами повинен існувати по Принаймні один роздільник (tspecials), бо інакше вони інтерпретуються як одна лексема.

2.2 Основні правила.


Наступні правила використовуються протягом всієї цієї специфікації для опису основних конструкцій синтаксичного аналізу. Кодований набір символів US-ASCII визначено в ANSI X3.4-1986
[21].
OCTET = <будь-яка 8-бітова послідовність даних>
CHAR = <будь US-ASCII символ (октети 0 - 127)>
UPALPHA = <будь US-ASCII символ верхнього регістру "A".."Z"> LOALPHA = <будь US-ASCII символ нижнього регістра "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <будь US-ASCII цифра "0" .. "9">
CTL = <будь US-ASCII керуючий символ (октети 0 - 31) і DEL (127)>
CR =
LF =
SP =
HT =
<"> =
HTTP/1.1 визначає послідовність CR LF як мітку кінця рядка у всіх елементах протоколу, за винятком тіла об’єкта (дивіться додаток 19.3 про допустимі застосуваннях (tolerant applications)). Мітка кінця рядки всередині тіла об’єкта визначається соответствиющім медіа типом, як описано в розділі 3.7.
CRLF = CR LF
HTTP/1.1 заголовки займають кілька рядків, якщо наступна рядок починається з пробілу або мітки горизонтальної табуляції. Всі незаповнений простір рядки, включаючи перехід на наступну рядок, має ту ж семантику, що і SP.
LWS = [CRLF] 1*( SP | HT )
Правило TEXT використовується тільки для описового вмісту поля і значень, які не призначені, для інтерпретації синтаксичним аналізатором повідомлень. Слова * TEXT можуть містити символи з наборів символів (character sets), відмінних від ISO 8859-1 [22], тільки коли вони закодовані згідно з правилами
RFC 1522 [14].
TEXT = <будь OCTET, за винятком CTLs, але містить LWS>
Шістнадцяткові цифри використовуються деякими елементами протоколу.
HEX = “A” | “B” | “C” | “D” | “E” | “F”
| “a” | “b” | “c” | “d” | “e” | “f” | DIGIT
Багато значення полів заголовка HTTP/1.1 складаються зі слів, розділених LWS або спеціальними символами. Ці спеціальні символи ПОВИННІ перебувати в цитованої рядку (quoted string), щоб бути використаними в якості значення параметра.
token = 1 * <будь CHAR за винятком CTLs або tspecials> tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT В деякі поля HTTP заголовка можуть бути включені коментарі. Текст коментаря оточується круглими дужками. Коментарі допускаються тільки в полях, що містять "comment" як частина визначення значення поля. У всіх інших полях круглі дужки розглядаються частиною значення поля. comment = "(" *( ctext | comment ) ")" ctext = <будь TEXT не включає "(" and ")">
Рядок тексту аналізується як одне слово, якщо це цитування, позначене подвійними лапками.
quoted-string = ( <“> *(qdtext) <“> )
qdtext = <будь TEXT не включає <">>
Символ похилій риси вліво (“\”) може використовуватися як Односимвольний механізм цитування тільки всередині конструкцій коментаря і рядки цитирования (quoted-string).
quoted-pair = “\” CHAR

3 Параметри протоколу.


3.1 Версія HTTP.


HTTP використовує схему нумерації типу “. “, Для вказівки версії протоколу. Стратегія версифікації протоколу призначена для того, щоб дозволити відправникові вказати формат повідомлення й свої здібності розуміння для подальшої HTTP зв’язку, перш ніж він отримає небудь за допомогою цього зв’язку. При додаванні компонентів повідомлення, які не впливають на поведінку зв’язку, або компонентів, які додаються тільки до розширюваним значенням поля, номер версії не змінюється. Коли внесені в протокол зміни додають можливості, які не змінюють загальний алгоритм аналізу повідомлень, але які розширюють семантику повідомлення і увазі додаткові можливості відправника, збільшується Номер. Коли формат повідомлення протоколу змінюється збільшується номер.
Версія HTTP повідомлення позначається полем HTTP-version в першій рядку повідомлення.
HTTP-Version = “HTTP” “/” 1*DIGIT “.” 1*DIGIT
Зверніть увагу, що major і minor числа ПОВИННІ оброблятися як окремі цілі числа і що кожне може складатися більш ніж з однієї цифри. Таким чином, HTTP/2.4 – нижча версія, ніж HTTP/2.13, яка в свою чергу нижче ніж HTTP/12.3. Нулі ПОВИННІ ігноруватися одержувачами і НЕ ПОВИННІ надсилатися.
Програми, що посилають повідомлення запитів або відповідей, які описує ця специфікація, ПОВИННІ включити HTTP версію (HTTP-version) “HTTP/1.1”. Використання цього номера версії вказує, що посилає додаток принаймні умовно сумісно з цією специфікацією.
HTTP версія програми – це найвища HTTP версія, для якої додаток є принаймні умовно сумісним.
Програми, що реалізують проксі-сервера і шлюзи, повинні бути уважні, коли пересилають повідомлення протоколу різних версій. Починаючи з моменту, коли версія протоколу вказує можливості відправника, проксі-сервер/шлюз ніколи НЕ ПОВИНЕН посилати повідомлення, версія яких більше, ніж HTTP версія відправника; якщо отримана більш висока версія запиту, то проксі-сервер/шлюз ПОВИНЕН або знизити версію запиту, віддавши повідомлення про помилку, або переключитися на тунельне поведінку. У запитів, версія яких нижче, ніж HTTP версія проксі-сервера/шлюза МОЖНА перед пересиланням збільшити версію; відповідь проксі-сервера/шлюза на цей запит ПОВИНЕН мати ту ж саму major версію, що й запит.
Зверніть увагу: Перетворення версій HTTP може включати модифікацію полів заголовка, необхідних або заборонених в цих версіях.

3.2 Універсальні Ідентифікатори Ресурсів (URI).


URI відомі під багатьма іменами: WWW адреси, Універсальні Ідентифікатори Документів, Універсальні Ідентифікатори Ресурсів (URI), і, на закінчення, як комбінація однакових Ідентифікаторів Ресурсу (Uniform Resource Locators, URL) і однакових Імен Ресурсу (Uniform Resource Names, URN). HTTP визначає URL просто як рядок певного формату, яка ідентифікує – через ім’я, розташування, або будь-яку іншу характеристику – ресурс.

3.2.1 Загальний синтаксис.


URI в HTTP можуть представлятися в абсолютній (absolute) формі або щодо деякої відомої основи URI (relative), в Залежно від контексту їх використання. Ці дві форми розрізняються тим, що абсолютні URI завжди починаються з імені схеми з двокрапкою.
URI = ( absoluteURI | relativeURI ) [ “#” fragment ]
absoluteURI = scheme “:” *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = “//” net_loc [ abs_path ]
abs_path = “/” rel_path
rel_path = [ path ] [ “;” params ] [ “?” query ]
path = fsegment *( “/” segment )
fsegment = 1*pchar
segment = *pchar
params = param *( “;” param )
param = *( pchar | “/” )
scheme = 1*( ALPHA | DIGIT | “+” | “-” | “.” )
net_loc = *( pchar | “;” | “?” )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | “:” | “@” | “&” | “=” | “+”
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = “%” HEX HEX
reserved = “;” | “/” | “?” | “:” | “@” | “&” | “=” | “+”
extra = “!” | “*” | “‘” | “(” | “)” | “,”
safe = “$” | “-” | “_” | “.”
unsafe = CTL | SP | <“> | “#” | “%” | “<” | “>” national = <будь OCTET за винятком ALPHA, DIGIT, reserved, extra, safe, і unsafe>
Повну інформацію щодо синтаксису і семантики URL дивіться RFC 1738 [4] І RFC 1808 [11]. Вищевказана нормальний запис Бекуса-Наура включає національні символи, недозволені в допустимих URL (це визначено в RFC 1738), так як HTTP сервери дозволяють використовувати для представлення частини rel_path адрес набір незарезервірованних символів, і, отже, HTTP проксі-сервера можуть отримувати запити URI, що не відповідають
RFC 1738.
Протокол HTTP не накладає a priori ніяких обмежень на довжини URI. Сервери ПОВИННІ бути здатні обробити URI будь-якого ресурсу, який вони обслуговують, і їм СЛІД бути в змозі обробляти URI необмеженої довжини, якщо вони обслуговують форми, засновані на методі GET, які можуть генерувати такий URI. Сервера СЛІД повертати код стану 414 (URI запиту занадто довгий, Request-URI Too Long), якщо URI більше, ніж сервер може обробити (Дивіться розділ 10.4.15).
Зверніть увагу: Сервери повинні бути обережні з URI, які мають довжину понад 255 байтів, бо деякі старі клієнти або проксі-сервера не можуть правильно підтримувати ці довжини.

3.2.2 HTTP URL.


“Http” схема використовується для доступу до мережевих ресурсів за допомогою протоколу HTTP. Цей розділ визначає схемо-певний синтаксис і семантику для HTTP URL.
http_URL = “http:” “//” host [ “:” port ] [ abs_path ]
host = <допустиме доменне ім'я машини або IP адресу (в точково-десяткового формі), як визначено в розділі 2.1 RFC 1123>
port = *DIGIT
Якщо порт порожній або не заданий – використовується порт 80. Це означає, що ідентифікований ресурс розміщений в сервері, що очікує TCP сполук на специфікованої порте port, комп’ютера host, і запитуваний URI ресурсу – abs_path. Використання IP адрес в URL СЛІД уникати, коли це можливо (дивіться RFC 1900 [24]). Якщо abs_path не представлений в URL, він ПОВИНЕН розглядатися як “/” При обчисленні запитуваної URI (Request-URI) ресурсу (Розділ 5.1.2).

3.2.3 Порівняння URI.


При порівнянні двох URI, щоб вирішити чи відповідають вони один одному чи ні, клієнтові СЛІД використовувати чутливе до регістру пооктетное (octet-by-octet) порівняння цих URI, з наступними виключеннями:
o Порт, який порожній або не вказаний, еквівалентний заданому по замовчуванням порту для цього URI;
o Порівняння імен хостів МАЄ проводитися без обліку регістра;
o Порівняння імен схем МАЄ проводитися без обліку регістра;
o Порожній abs_path еквівалентний “/”.
Символи, відмінні від тих, що знаходяться в “зарезервованих” (“Reserved”) і “небезпечних” (“unsafe”) наборах (див. розділ 3.2) еквівалентні їх кодування як “”% “HEX HEX”.
Наприклад наступні три URI еквівалентні:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

3.3 Формати дати / часу.


3.3.1 Повна дата.


HTTP програми історично допускали три різних формату для представлення дати / часу:
Sun, 06 Nov 1994 8:49:37 GMT; RFC 822, доповнений в RFC 1123 Sunday, 06-Nov-94 8:49:37 GMT; RFC 850, переписаний як RFC 1036 Sun Nov 6 8:49:37 1994; формат asctime () ANSI C
Перший формат обраний в якості стандарту Інтернету і являє підмножина фіксованої довжини, як визначено в RFC 1123 (Модифікованому RFC 822). Другий формат знаходиться в загальному користуванні, але заснований на застарілому і втратив статус стандарту RFC 850 [12], що описує формати дат, він володіє тим недоліком, що рік вказується не в чотирирозрядний нотації. Клієнти та сервери HTTP/1.1, які аналізують значення дати, ПОВИННІ розуміти всі три формату (для сумісності з HTTP/1.0), але генерувати для представлення значень дат в полях заголовка HTTP ПОВИННІ тільки формат RFC 1123.
Зверніть увагу: Заохочується практика, при якій одержувачі значень дат здраво сприймають значення дат, які, можливо, послані не HTTP додатками, що має місце при завантаженні або реєстрації повідомлень через проксі-сервера/шлюзи до SMTP або NNTP.
Всі без винятків формати HTTP дати / часу ПОВИННІ бути представлені в Greenwich Mean Time (GMT). У перших двох форматах даний факт вказується включенням трехсімвольного скорочення “GMT” в якості часового поясу. В asctime () форматі це ПОВИННО матися на увазі при читанні.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday “,” SP date1 SP time SP “GMT”
rfc850-date = weekday “,” SP date2 SP time SP “GMT”
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT ; День місяць рік (наприклад 02 Jun 1982)
date2 = 2DIGIT “-” month “-” 2DIGIT ; День-місяць-рік (напрмер 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) ; Місяць день (наприклад, Jun 2)
time = 2DIGIT “:” 2DIGIT “:” 2DIGIT
; 00:00:00 – 23:59:59
wkday = “Mon” | “Tue” | “Wed”
| “Thu” | “Fri” | “Sat” | “Sun”
weekday = “Monday” | “Tuesday” | “Wednesday”
| “Thursday” | “Friday” | “Saturday” | “Sunday”
month = “Jan” | “Feb” | “Mar” | “Apr”
| “May” | “Jun” | “Jul” | “Aug”
| “Sep” | “Oct” | “Nov” | “Dec”
Зверніть увагу: Ці вимоги – це вимоги до для форматам дати / часу, які застосовуються всередині потоку протоколу HTTP. Клієнтам і серверів не потрібно використовувати ці формати для подання користувачеві, реєстрації запитів і т.д.

3.3.2 Різниця секунд (delta seconds).


Деякі поля HTTP заголовка дозволяють вказувати значення часу у вигляді цілого числа секунд, представленого в десятковій формі, які повинні пройти з того моменту, як повідомлення було отримано.
delta-seconds = 1*DIGIT

3.4 Кодові таблиці (character sets).


HTTP використовує те ж саме визначення терміна “кодова таблиця”, яке описано для MIME:
Термін “кодова таблиця” використовується в даному документі, щоб послатися на метод, що використовує одну або декілька таблиць для перетворення послідовності октетів в послідовність символів. Варто зазначити, що однозначне перетворення в зворотному напрямку не потрібно, і що не всі символи можуть бути доступні в даній кодової таблиці, і що кодова таблиця може забезпечувати більш ніж одну послідовність октетів для подання специфічних символів. Це визначення допускає різні види кодування символів, від простих однотаблічних відображень типу US-ASCII до складних методів, перемикаючих таблиці, на зразок тих, які використовують методики ISO 2022. Однак визначення, пов’язане з ім’ям кодової таблиці MIME ПОВИННО повністю визначати відображення, яке перетворює октети в символи. Зокрема використання зовнішньої інформації профілювання для визначення точного відображення не дозволяється.
Зверніть увагу: Це використання терміну “кодова таблиця” зазвичай згадується як “кодування символів”. Однак, з тих пір як HTTP і MIME спільно використовують одіннаковом запис, важливо, щоб збігалася також і термінологія.
Кодові таблиці HTTP ідентифікуються лексемами, не чутливими до регістру. Повний набір лексем визначено реєстром кодових таблиць
IANA [19].
charset = token
Хоча HTTP дозволяє використовувати в якості значення charset довільну лексему, будь-яка лексема, яка має зумовлене значення в реєстрі кодових таблиць IANA, ПОВИННА представляти набір символів, визначений в даному реєстрі. Додатків СЛІД обмежити використання символьних наборів тими, які визначені в реєстрі IANA.

3.5 Кодування вмісту (content codings).


Значення кодування вмісту вказує яке перетворення кодування було чи буде застосовано до об’єкта. Кодування вмісту використовується насамперед для стиснення або іншого корисного перетворення до документа без втрати ідентифікації основного медіа типу та інформації. Часто, об’єкт зберігається в кодованої формі, потім передається, а потім декодується одержувачем.
content-coding = token
Всі значення кодування вмісту (content-coding) не чутливі до регістру. HTTP/1.1 використовує значення кодування вмісту (content-coding) в полях заголовка Accept-Encoding (Розділ 14.3) і Content-Encoding (розділ 14.12). Хоча значення описує кодування вмісту, але, що більш важливо – воно вказує, який механізм декодування потрібно для зворотного процесу.
Internet Assigned Numbers Authority (IANA) діє як реєстр для значень лексем кодування вмісту (content-coding). Спочатку реєстр містив наступні лексеми:
gzip Формат кодування, що виробляє стиснення файлу програмою “gzip” (GNU zip), як описано в RFC 1952 [25]. Це формат Lempel-Ziv кодування (LZ77) з 32 розрядним CRC.
compress Формат кодування, вироблений загальною програмою “compress” для стиснення UNIX файлів. Це формат адаптивного Lempel-Ziv-Welch кодування (LZW).
Зверніть увагу: Використовувати назви програм для ідентифікації форматів кодування не бажано і повинно бути не зрозуміло майбутнім кодування. Їх використання тут пояснюється історичною практикою, але так робити не потрібно. Для сумісності з попередніми реалізаціями HTTP, додатки повинні розглядати “x-gzip” і “x-compress” як еквіваленти “gzip” і “Compress” відповідно.
deflate Формат zlib, визначений в RFC 1950 [31], в комбінації з механізмом стиснення “deflate”, описаним в RFC 1951 [29].
Нова лексема значення кодування вмісту (content-coding) повинна бути зареєстрована; щоб забезпечити взаємодію між клієнтами і серверами, специфікація алгоритму кодування вмісту, необхідного для визначення нового значення, повинна бути відкрито опублікована і адекватна для незалежної реалізації, а також відповідати меті кодування вмісту певного в цьому розділі.

3.6 Кодування передачі (Transfer Codings).


Значення кодування передачі використовуються для вказівки перетворення кодування, яке було або повинно бути застосовано до тіла об’єкта (entity-body) з метою гарантування “безпечної передачі “по мережі. Воно відрізняється від кодування вмісту тим, що кодування передачі – це властивість повідомлення, а не первісного об’єкта.
transfer-coding = “chunked” | transfer-extension
transfer-extension = token
Всі значення кодування передачі (transfer-coding) не чутливі до регістру. HTTP/1.1 використовує значення кодування передачі (transfer-coding) в поле заголовка Transfer-Encoding (Розділ 14.40).
Кодування передачі – це аналоги значень Content-Transfer-Encoding MIME, які були розроблені для забезпечення безпечної передачі двійкових даних при використанні 7-бітного обслуговування передачі. Однак безпечний транспорт має інше призначення для чисто 8-бітного протоколу передачі. У HTTP єдина небезпечна характеристика тіла повідомлення викликана складністю визначення точної довжини тіла повідомлення (розділ 7.2.2), чи бажанням шифрувати дані при користуванні загальнодоступним транспортом.
Кодування по шматках (chunked encoding) змінює тіло повідомлення для передачі його послідовністю шматків, кожен з яких має власний індикатор розміру, супроводжуваним опціональним завершителем, що містить поля заголовка об’єкта. Це дозволяє динамічно створюваного вмісту передаватися разом з інформацією, необхідною одержувачу для перевірки повноти отримання повідомлення.
Chunked-Body = *chunk
“0” CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero =
chunk-size = hex-no-zero *HEX
chunk-ext = *( “;” chunk-ext-name [ “=” chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
footer = *entity-header
Кодування по шматках (chunked encoding) закінчується шматком нульового розміру, наступним за завершителем, що закінчується порожній рядком. Мета завершітеля полягає в ефективному методі забезпечення інформації про об’єкт, який згенерований динамічно; програми НЕ ПОВИННІ посилати в завершителем поля заголовка, які явно не призначені для використання в завершителем, такі як Content-MD5 або майбутні розширення HTTP для цифрових підписів і інших можливостей.
Приблизний процес декодування Chunked-Body представлений в додатку 19.4.6.
Всі HTTP/1.1 програми ПОВИННІ бути в стані отримувати і декодувати кодування передачі “по шматках” (“chunked” transfer coding), і ПОВИННІ ігнорувати розширення кодування передачі, які вони не розуміють. Серверу, який отримав тіло об’єкта зі значенням кодування передачі, який він не розуміє, СЛІД повернути відповідь з кодом 501 (Не реалізовано, Not Implemented) і розірвати з’єднання. Сервер НЕ ПОВИНЕН посилати поля кодування передачі (transfer-coding) HTTP/1.0 клієнтам.

3.7 Медіа типи (Media Types).


HTTP використовує Медіа Типи Інтернету (Internet Media Types) в полях заголовка Content-Type (розділ 14.18) і Accept (розділ 14.1) для забезпечення відкритої і розширюваної типізації даних і обговорення типів.
media-type = type “/” subtype *( “;” parameter )
type = token
subtype = token
Параметри можуть слідувати за type / subtype у формі пар атрибут / значення (attribute / value).
parameter = attribute “=” value
attribute = token
value = token | quoted-string
Тип, підтип, і імена атрибутів і параметрів не чутливі до регістру. Значення параметрів можуть бути чутливими до регістру, але можуть бути і не чутливі, в залежності від семантики імені параметра. Лінійний пробіл (LWS) НЕ ПОВИНЕН використовуватися між типом і підтипом, між атрибутом і значенням. Агенти користувачів, розпізнають медіа типи, ПОВИННІ обробляти (або готувати для обробки будь-якими зовнішніми додатками) параметри для тих типів MIME, які описані, і повідомляти користувачу про виявлених проблемах.
Зверніть увагу: Деякі старі HTTP програми не розпізнають параметри медіа типів. При посилці даних до таких HTTP додатків реалізації повинні використовувати параметри медіа типів тільки коли це потрібно за визначенням типу / підтипу.
Значення медіа-типів реєструються Internet Assigned Number Authority (IANA). Процес реєстрації медіа типу визначено в RFC 2048 [17]. Використання не зареєстрованих медіа типів вводить в оману.

3.7.1 Канонізація і зумовлені значення типу text.


Медіа типи Інтернету зареєстровані в канонічній формі. Взагалі, тіло об’єкта, що передається HTTP повідомленням, ПОВИННО бути представлено у відповідній канонічній формі до передачі; виняток складають типи “text”, які визначаються в наступному абзаці.
У канонічної формі медіа підтипи типу “text” використовують CRLF в Як мітки кінця рядка. HTTP послаблює цю вимогу і дозволяє передавати текст розмічений таким чином, що еденічние CR або LF можуть бути мітками кінця рядка, правда це правило повинно бути виконано для всього тіла об’єкта (entity-body). HTTP програми ПОВИННІ сприймати CRLF, просто CR, і просто LF як подання кінця рядка в текстових типах, переданих по HTTP. Крім того, якщо текст представляється у кодовій таблиці, яка не використовує октети 13 і 10 для CR і LF відповідно, що має місце в деяких мультибайтних кодових таблицях, то HTTP дозволяє використовувати будь-які послідовності октетів, визначені цим набором символів для представлення еквівалентів CR і LF в якості коду кінця рядка. Ця гнучкість щодо решт рядків застосовна тільки до текстових типам в тілі об’єкта; просто CR або просто LF НЕ ПОВИННІ замінювати CRLF всередині будь керуючої структури HTTP (типу поля заголовка і роздільників типу multipart).
Якщо тіло об’єкта кодується за допомогою Content-Encoding, то основні дані ПОВИННІ бути в певній вище формі до кодування.
Параметр “charset” використовується з деякими медіа типами для вказівки кодової таблиці (розділ 3.4), що використовується для представлення даних. Якщо параметр “charset” не вказано відправником, то при отриманні по HTTP медіа підтипи типу “text” мають значення “charset”, за замовчуванням дорівнює “ISO-8859-1”. Дані в кодових таблицях або їх подмножествах, відмінних від “ISO-8859-1” ПОВИННІ бути позначені відповідним значенням “charset”.
Деякий програмне забезпечення HTTP/1.0 інтерпретувало заголовок Content-Type без параметра “charset” неправильно, як означає “повинен припустити одержувач”. Відправники, які бажають передбачити таку поведінку МОЖУТЬ включати параметр “charset” навіть коли charset дорівнює ISO-8859-1 і ПОВИННІ зробити це, якщо відомо, що це не заплутає одержувача.
На жаль, деякі старі HTTP/1.0 клієнти не працювали правильно з визначенням параметра “charset”. HTTP/1.1 одержувачі ПОВИННІ віддавати пріоритет мітці “charset”, поставленої відправником, і ті агенти користувачів, які мають можливість “передбачити” charset ПОВИННІ при первинному відображенні документа використовувати charset з поля content-type, якщо вони підтримують такий charset, а потім використовувати власні установки.

3.7.2 Типи Multipart.


MIME передбачає ряд типів “multipart” – формують пакет з одного або декількох об’єктів усередині тіла одного повідомлення. Всі типи mulptipart використовують загальний синтаксис, визначений у MIME [7], і ПОВИННІ містити розділовий параметр частиною значення медіа типу. Тіло повідомлення – самостійний елемент протоколу і, отже, МАЄ використовувати тільки СRLF для подання решт рядків між частинами тіла (body-parts). На відміну від MIME, закінчення будь-якого multipart повідомлення ПОВИННО бути порожнім; HTTP додатка НЕ ​​ПОВИННІ передавати закінчення (навіть якщо початковий multipart містить висновок).
У HTTP частини тіла (body-parts) типу multipart МОЖУТЬ містити поля заголовка, які є значущими в прімненіі до цієї частини. Поле заголовка Content-Location (розділ 14.15) СЛІД включати в частина тіла (body-part) кожного включеного об’єкта, який може бути ідентифікований URL.
Взагалі кажучи, HTTP агенту користувача СЛІД дотримуватися такого ж або подібної поведінки, якому слідував б MIME агент користувача після отримання типу multipart. Якщо додаток отримує незареєстрований підтип multipart, воно ПОВИННО обробляти його як підтип “multipart / mixed”.
Зверніть увагу: тип “multipart / form-data” був спеціально визначений для передачі даних форми, що підходять для обробки методом запиту POST, що описано в RFC 1867 [15].

3.8 Лексеми програм (Product Tokens).


Лексеми програм використовуються, щоб забезпечити комунікаційним додаткам можливість ідентифікувати себе назвою і версією програмного забезпечення. Більшість полів, що використовують лексеми програм також допускає перерахування підпрограм, які формують значну частину програми, і які перераховуються через пробіл. Відповідно до угоди, підпрограми перераховуються в порядку їх значення для ідентифікації програми.
product = token [“/” product-version]
product-version = token
Приклади:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Лексеми програм повинні бути короткими і по суті – використання їх для реклами або іншого несуттєвою інформації однозначно заборонено. Хоча в лексеме product-version може зустрічатися будь символ, все ж її слід використовувати тільки для ідентифікатора версії (тобто, послідовним версіями однієї і тієї ж програми СЛІД мати відмінності тільки в частині product-version лексеми
product.

3.9 Якісні значення (Quality Values).


Обговорення вмісту HTTP (розділ 12) використовує короткі числа “з плаваючою точкою “для вказівки відносної важливості (” ваги “) різних обумовлених параметрів. Вага – це нормалізованності дійсне число в діапазоні від 0 до 1, де 0 – мінімальне, а 1 – максимальне значення. HTTP/1.1 додатка НЕ ​​ПОВИННІ генерувати більше трьох цифр після десяткової точки. Користувальницьким конфігурацій цих значень СЛІД також обмежуватися цим режимом.
qvalue = ( “0” [ “.” 0*3DIGIT ] )
| ( “1” [ “.” 0*3(“0”) ] )
“Якісні значення” – не коректне назву, тому що ці значення просто представляють відношення зниження продуктивності до бажаного якості.

3.10 Мітки мов (Language Tags).


Мітка мови ідентифікує природну мову: розмовний, письмовий, або інший використовуваний людьми для обміну інформацмей з іншими людьми. Машинні мови є винятком. HTTP використовує мітки мови всередині полів Accept-Language і
Content-Language.
Синтаксис і запис HTTP міток мови такі ж, як визначаються RFC 1766 [1]. В резюме, мітка мови складається з однієї або декількох частин: мітка первинного мови і, можливо порожній, ряд підлеглих міток:
language-tag = primary-tag *( “-” subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Усередині мітки не допустимо прогалину і все мітки не чутливі до регістру. Простір імен міток мови управляється IANA. Наприклад мітки містять:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Будь однорядкове резюме первинна мітка є міткою Аббревеатура мови ISO 639, а будь-яка однорядкове резюме підпорядкована мітка є міткою коду країни ISO 3166. (Останні три мітки з перерахованих вище – не зареєстровані мітки; все, крім останньої – приклади міток, які могли б бути зареєстровані в майбутньому.)

3.11 Мітки об’єктів (Entity Tags).


Мітки об’єктів використовуються для порівняння двох або більше об’єктів від одного і того ж запитаного ресурсу. HTTP/1.1 використовує мітки об’єкта в полях заголовка ETag (розділ 14.20), If-Match (розділ 14.25), If-None-Match (розділ 14.26), і If-Range (розділ 14.27). Визначення того, як вони використовуються і порівнюються у якості міток перевірки кешу знаходиться в розділі 13.3.3. Мітка об’єкта складається з непрозорої цитованої рядка (opaque quoted string), можливо упереджені індикатором слабкості (weakness indicator).
entity-tag = [ weak ] opaque-tag
weak = “W/”
opaque-tag = quoted-string
“Сильна мітка об’єкта” (“strong entity tag”) може бути розділена двома об’єктами ресурсу, тільки якщо вони пооктетно еквівалентні.
“Слабка мітка об’єкта” (“weak entity tag”), обозначяемая префіксом “W /”, може бути розділена двома об’єктами ресурсу тільки якщо об’єкти еквівалентні і могли б заміняти один одного без значної зміни в семантиці. Слабка мітка об’єкта може використовуватися тільки для слабкого порівняння.
Мітка об’єкта ПОВИННА бути унікальна серед всіх версій всіх об’єктів, пов’язаних з конкретним ресурсом. Дане значення мітки об’єкту може використовуватися для об’єктів, отриманих запитами різних URI без припущення еквівалентності цих об’єктів.

3.12 одиниці виміру діапазонів (Range Units).


HTTP/1.1 дозволяє клієнту запитувати тільки частина об’єкта. HTTP/1.1 використовує одиниці виміру діапазонів в полях заголовка Range (розділ 14.36) і Content-Range (розділ 14.17). Об’єкт може бути розбитий на частини відповідно різним структурним модулям.
range-unit = bytes-unit | other-range-unit
bytes-unit = “bytes”
other-range-unit = token
Єдина еденица вимірювання діапазонів, визначена в HTTP/1.1 – Це “bytes”. Реалізації HTTP/1.1 можуть ігнорувати діапазони, визначені з використанням інших одиниць виміру. HTTP/1.1 був розроблений, щоб допускати реалізації програм, які не залежать від знання діапазонів.

4 HTTP повідомлення (HTTP Message).


4.1 Типи повідомлень.


HTTP повідомлення діляться на запити клієнта серверу та відповіді сервера клієнту.
HTTP-message = Request | Response; повідомлення HTTP/1.1
Повідомлення запиту (розділ 5) і відповіді (розділ 6) використовують узагальнений формат повідомлення RFC 822 [9] для переміщення об’єктів (Корисного навантаження повідомлення). Обидва типи повідомлень виглядають наступним чином: спочатку йде початкова рядок (start-line), потім один або кілька полів заголовка (званих також просто “Заголовки”), потім порожній рядок (тобто рядок, рівна CRLF), вказує кінець полів заголовка, а потім, можливо, тіло повідомлення.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
В інтересах ошібкоустойчівості, серверам СЛІД ігнорувати всі порожні рядки, отримані перед рядком запиту (Request-Line). Іншими словами, якщо сервер читає потік протоколу і в самому початку повідомлення отримує CRLF, то йому слід цей CRLF ігнорувати.
Зверніть увагу: деякі помилкові реалізації HTTP/1.0 клієнтів генерують додаткові CRLF після запиту POST. Варто знову повторити, що це явно заборонено нормальної записом Бекуса-Наура. HTTP/1.1 клієнт не повинен додавати додаткові CRLF перед запитом і після нього.

4.2 Заголовки повідомлень.


Поля заголовків HTTP, які включають поля загальних заголовків (General-header) (розділ 4.5), заголовків запиту (request-header) (Розділ 5.3), заголовків відповіді (response-header) (розділ 6.2), і заголовків об’єкта (entity-header) (розділ 7.1), мають такий же узагальнений формат, що описаний в розділі 3.1 RFC 822 [9]. Кожне поле заголовка складається з імені, двокрапки (“:”) і значення поля. Імена полів не чутливі до регістру. Значенням поля може передувати будь-яке число LWS, хоча переважний одиночний SP. Поля заголовка можуть займати кілька рядків. При цьому кожна наступний рядок починається принаймні одним SP або HT. Додатків СЛІД дотримуватися “загальної форми” (“common form”) при генерації HTTP конструкцій, так як можуть існувати реалізації, які не в змозі приймати що-небудь крім загальних форм.
message-header = field-name “:” [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <октети, що становлять значення поля і складаються або з * TEXT або з комбінацій лексем, tspecials, і quoted-string>
Порядок, в якому отримані поля заголовка з різними іменами не має значення. Проте “хороша практика” полягає в тому, що спочатку надсилаються поля загальних заголовків, потім поля заголовків запиту або заголовків відповіді, і, нарешті, поля заголовків об’єкта.
Кілька полів заголовка з одіннаковом іменами можуть бути присутнім в повідомленні тоді, і тільки тоді, коли всі значення полів, які входять в заголовок, визначають розділений комами список [тобто # (value)]. ПОВИННО бути можливо об’єднати декілька таких полів заголовка в одну пару “ім’я поля: значення поля “(не зміни цим семантику повідомлення) приєднуючи кожне наступне значення поля до першого через коми. Порядок, в якому отримані поля з однаковими іменами, має значення для інтерпретації об’єднаного значення поля, і, отже, проксі-сервер НЕ ПОВИНЕН змінювати порядок значень цього поля при пересиланні.

4.3 Тіло Cообщения.


Тіло HTTP повідомлення (message-body), якщо воно присутнє, використовується для передачі тіла об’єкта, пов’язаного із запитом або відповіддю. Тіло повідомлення (message-body) відрізняється від тіла об’єкта (Entity-body) тільки в тому випадку, коли застосовується кодування передачі, що вказується полем заголовка Transfer-Encoding (Розділ 14.40).
message-body = entity-body |

4.4 Довжина повідомлення.


Коли тіло повідомлення (message-body) присутня в повідомленні, довжина цього тіла визначається одним з таких методів (в порядку старшинства):
1. Будь-яке повідомлення відповіді, яке НЕ МАЄ включати тіло повідомлення (message-body) (наприклад відповіді з кодами стану 1xx, 204, 304 і всі відповіді на запит HEAD) завжди завершується порожній рядком після полів заголовка, незалежно від полів заголовка об’єкта (entity-header fields), представлених в повідомленні.
2. Якщо поле заголовка Transfer-Encoding (розділ 14.40) присутній і вказує на застосування кодування передачі “Chunked”, то довжина визначається кодуванням по шматках (Chunked encoding) (розділ 3.6).
3. Якщо поле заголовка Content-Length (розділ 14.14) присутній, то його значення представляє довжину тіла повідомлення (Message-body) в байтах.
4. Якщо повідомлення використовує медіа тип “multipart / byteranges”, який саморазгранічен, то він і визначає довжину. Цей медіа тип НЕ ПОВИНЕН використовуватися, якщо відправник не знає, що одержувач може його обробити; присутність в запиті заголовка Range з кількома специфікаторами діапазонів байтів (Byte-range) передбачає, що клієнт може аналізувати multipart / byteranges відповіді.
5. Довжина визначається закриттям з’єднання сервером. (Закриття з’єднання не може використовуватися для вказівки кінця тіла запиту, так як в цьому випадку у сервера не залишається жодної можливості послати назад відповідь).
Для сумісності з HTTP/1.0 додатками HTTP/1.1 запити, містять тіло повідомлення (message-body) ПОВИННІ включати допустиме поле заголовка Content-Length, якщо не відомо, що сервер є HTTP/1.1 сумісним. Якщо запит містить тіло повідомлення (message-body), і Content-Length не вказано, серверу СЛІД послати відповідь з кодом стану 400 (Зіпсований Запит, Bad Request), якщо він не може визначити довжину повідомлення, або з кодом стану 411 (Потрібно довжина, Length Required), якщо він наполягає на отриманні Content-Length.
Всі HTTP/1.1 додатки, які отримують об’єкти, ПОВИННІ розуміти кодування передачі типу “chunked” (розділ 3.6), таким чином дозволяється використання даного механізму для таких повідомлень, довжина яких не може бути визначена заздалегідь.
Повідомлення НЕ ПОВИННІ одночасно включати і поле заголовка Content-Length і застосовувати кодування передачі типу “chunked”. Якщо надійшло повідомлення з полем Content-Length і закодоване із застосуванням кодування передачі “chunked”, то поле Content-Length МАЄ ігноруватися.
Якщо поле Content-Length присутній в повідомленні, яке допускає наявність тіла повідомлення (message-body), то значення поля ПОВИННО точно відповідати числу октетів в тексті листа. HTTP/1.1 агенти користувача ПОВИННІ інформувати користувача в разі отримання та виявлення неприпустимою довжини.

4.5 Загальні поля заголовка.


Є кілька полів заголовка, які застосовуються як для повідомлень запитів, так і для повідомлень відповідей, але які не застосовуються до переданому об’єкту. Ці поля заголовка застосовуються тільки до переданому повідомленню.
general-header = Cache-Control; Розділ 14.9 | Connection; Розділ 14.10 | Date; Розділ 14.19 | Pragma; Розділ 14.32 | Transfer-Encoding; Розділ 14.40 | Upgrade; Розділ 14.41 | Via; Розділ 14.44
Імена загальних полів заголовка (general-header fields) можуть бути надійно розширені тільки в поєднанні зі зміною версії протоколу. Однак, нові або експериментальні поля заголовка можуть отримати семантику загальних полів заголовка (general-header fields), якщо всі сторони з’єднання розпізнають їх як загальні поля заголовка. Нерозпізнані поля заголовка обробляються як поля заголовка об’єкта (entity-header).

5 Запит (Request).


Повідомлення запиту від клієнта до сервера містить в першому рядку: метод, який потрібно застосувати до ресурсу, ідентифікатор ресурсу і використовувану версію протоколу.
Request = Request-Line; Розділ 5.1 * (General-header; Розділ 4.5 | Request-header; Розділ 5.3 | Entity-header); Розділ 7.1
CRLF [Message-body]; Розділ 7.2

5.1 Рядок запиту (Request-Line).


Рядок запиту (Request-Line) починається з лексеми методу, потім слід запитуваний URI (Request-URI), версія протоколу та CRLF. Ці елементи розділяються SP. У рядку запиту (Request-Line) не допустимі CR і LF, виняток становить кінцева послідовність CRLF.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Метод (Method).


Лексема методу вказує метод, який потрібно застосувати до ресурсу, ідентифікованому запитуваною URI (Request-URI). Метод чутливий до регістру.
Method = “OPTIONS”; Розділ 9.2 | “GET”; Розділ 9.3 | “HEAD”; Розділ 9.4 | “POST”; Розділ 9.5 | “PUT”; Розділ 9.6 | “DELETE”; Розділ 9.7 | “TRACE”; Розділ 9.8
| extension-method
extension-method = token
Список методів, що застосовуються до ресурсу, може бути зазначений в поле заголовка Allow (розділ 14.7). Возврашает код стану відповіді завжди повідомляє клієнту, припустимо чи метод для ресурсу в даний час, так як набір допустимих методів може змінюватися динамічно. Серверів СЛІД повернути код стану 405 (Метод не дозволений, Method Not Allowed), якщо метод відомий серверу, але не застосуємо для запитаного ресурсу, і 501 (Не реалізовано, Not Implemented), якщо метод не розпізнано або не реалізований сервером. Список методів, відомих серверу, може бути зазначений в поле заголовка відповіді Public (розділ 14.35).
Методи GET і HEAD ПОВИННІ підтримуватися усіма універсальними (General-purpose) серверами. Решта методів опційні, а проте, якщо вищезгадані методи реалізовані, то вони ПОВИННІ мати семантику, описану в розділі 9.

5.1.2 Запитуваний URI (Request-URI).


Запитуваний URI (Request-URI) – це Однаковий Ідентифікатор Ресурсу (URL, розділ 3.2), який ідентифікує ресурс запиту.
Request-URI = “*” | absoluteURI | abs_path
Три опції для запитуваної URI (Request-URI) залежать від характеру запиту. Зірочка “*” означає, що запит звертається не до специфічного ресурсу, а до сервера безпосередньо, і допускається тільки в тому випадку, коли використовується метод не обов’язково звертається до ресурсу. Як приклад:
OPTIONS * HTTP/1.1
absoluteURI необхідний, коли запит проводиться через проксі-сервер. Проксі-сервер перенаправляє запит на сервер або обслуговує його, користуючись кешем, і повертає відповідь. Зверніть увагу, що проксі-сервер МОЖЕ переслати запит іншому проксі-сервера або безпосередньо серверу, визначеному absoluteURI. Щоб уникнути зациклення запиту проксі-сервер ПОВИНЕН бути здатний розпізнавати всі імена сервера, включаючи будь-які псевдоніми, локальні різновиди, і числові IP адреси. Request-Line може бути, наприклад, таким:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Щоб забезпечити перехід до absoluteURI у всіх запитах в майбутніх версіях HTTP, все HTTP/1.1 сервери ПОВИННІ приймати absoluteURI у запитах, хоча HTTP/1.1 клієнти будуть генерувати їх тільки в запитах до проксі-серверів.
Найбільш загальна форма Request-URI – та, яка використовується для ідентифікації ресурсу на первинному сервері або шлюзі. В цьому випадку абсолютний шлях URI (дивіться розділ 3.2.1, abs_path) ПОВИНЕН бути переданий як Request-URI, а мережеве розташування URI (Net_loc) ПОВИННО бути передано в поле заголовка Host. Для останнього прикладу клієнт, який бажає отримати ресурс безпосередньо з початкового сервера повинен створити TCP з’єднання на 80 порт хоста “www.w3.org” і послати рядки:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
і далі залишок запиту. Зверніть увагу, що абсолютний шлях не може бути порожнім, якщо оригінальний URI порожній, то він ПОВИНЕН запитуватися як “/” (кореневий каталог сервера).
Якщо проксі-сервер отримує запит без шляху в Request-URI, і метод запиту допускає форму запиту “*”, то останній проксі-сервер в ланцюжку запитів ПОВИНЕН передати запит, в якому Request-URI дорівнює “*”. Наприклад запит
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
був би переданий проксі-сервером у вигляді
OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001
після з’єднання з портом 8001 хоста “www.ics.uci.edu”.
Request-URI передається у форматі, визначеному в розділі 3.2.1. Початковий сервер ПОВИНЕН декодувати Request-URI, щоб правильно інтерпретувати запит. Серверів СЛІД відповідати на неприпустимі Request-URI відповідним кодом стану.
У запитах, що передаються далі, проксі-сервера ніколи НЕ ПОВИННІ перезаписувати частина “abs_path” запитуваної URI (Request-URI), за винятком випадку, зазначеного вище, коли порожній abs_path замінюється на “*”, незалежно від внутрішньої реалізації проксі-сервера.
Зверніть увагу: правило “ніщо не перезаписувати” оберігає проксі-сервера від зміни значення запиту, в якому первинний сервер неправильно використовує не зарезервовані символи URL для своїх цілей. Реалізаторам слід знати, що деякі до-HTTP/1.1 проксі-сервера, як відомо, перезаписували Request-URI.

5.2 Ресурс, ідентифікований запитом.


Початкові HTTP/1.1 сервера ПОВИННІ враховувати, що точний ресурс, ідентифікований інтернет-запитом визначається дослідженням як Request-URI, так і поля заголовка Host.
Початковий сервер, який не дозволяє ресурсам відрізнятися за запрошенням хосту (host), МОЖЕ ігнорувати значення поля заголовка Host. (Але дивіться розділ 19.5.1 для інших вимог з підтримки Host в HTTP/1.1).
Початковий сервер, який розрізняє ресурси, засновані на запрошенном хості (іноді звані віртуальними хостами або vanity hostnames) ПОВИНЕН використовувати наступні правила для визначення запитаного в HTTP/1.1 запиті ресурсу:
1. Якщо Request-URI – це absoluteURI, то хост – це частина Request-URI. Будь-яке значення поля заголовка Host в запиті ПОВИННО ігноруватися.
2. Якщо Request-URI – не absoluteURI, а запит містить поле заголовка Host, то хост визначається значенням поля заголовка Host.
3. Якщо хоста, визначеного правилами 1 або 2 не існує на сервері, код стану відповіді ПОВИНЕН бути 400 (Зіпсований Запит, Bad Request).
Одержувачі HTTP/1.0 запиту, в якому бракує поля заголовка Host, МОЖУТЬ намагатися використовувати евристику (наприклад, дослідити шлях в URI на предмет унікальності на якомусь із хостів) щоб визначити який точно ресурс запитується.

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


Поля заголовка запиту дозволяють клієнту передавати серверу додаткову інформацію про запит і про самого клієнта. Ці поля діють як модифікатори запиту з семантикою, еквівалентній параметрами виклику методів в мовах програмування.
request-header = Accept; Розділ 14.1 | Accept-Charset; Розділ 14.2 | Accept-Encoding; Розділ 14.3 | Accept-Language; Розділ 14.4 | Authorization; Розділ 14.8 | From; Розділ 14.22 | Host; Розділ 14.23 | If-Modified-Since; Розділ 14.24 | If-Match; Розділ 14.25 | If-None-Match; Розділ 14.26 | If-Range; Розділ 14.27 | If-Unmodified-Since; Розділ 14.28 | Max-Forwards; Розділ 14.31 | Proxy-Authorization; Розділ 14.34 | Range; Розділ 14.36 | Referer; Розділ 14.37 | User-Agent; Розділ 14.42
Імена полів заголовка запиту (Request-header) можуть бути надійно розширені тільки в поєднанні зі зміною версії протоколу. Однак, нові або експериментальні поля заголовка можуть отримати семантику полів заголовка запиту (Request-header), якщо всі сторони з’єднання розпізнають їх як поля заголовка запиту (Request-header). Нерозпізнані поля заголовка обробляються як поля заголовка об’єкта (entity-header).

6 Відповідь (Response).


Після отримання та інтерпретації повідомлення запиту, сервер відповідає повідомленням HTTP відповіді.
Response = Status-Line; Розділ 6.1 * (General-header; Розділ 4.5 | Response-header; Розділ 6.2 | Entity-header); Розділ 7.1
CRLF [Message-body]; Розділ 7.2

6.1 Рядок стану (Status-Line).


Перший рядок відповіді – це рядок стану (Status-Line). Вона складається з версії протоколу (HTTP-Version), числового коду стану (Status-Code) і пояснюючим фрази (Reason-Phrase), розділених символами SP. CR і LF не припустимі в Status-Line, за винятком кінцевої послідовності CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Код стану і пояснює фраза.


Елемент код стану (Status-Code) – це цілочисельний трехразрядного код результату розуміння та задоволення запиту. Ці коди повністю визначені в розділі 10. Пояснює фраза (Reason-Phrase) призначена для короткого текстового опису коду стану. Код стану (Status-Code) призначений для використання автоматами, а пояснююча фраза призначена для живих користувачів. Від клієнта не потрібно досліджувати чи відображати пояснює фразу (Reason-Phrase).
Перша цифра коду стану визначає клас відповіді. Останні дві цифри не мають певної ролі в класифікації. Є 5 значень першої цифри:
o 1xx: Інформаційні коди – запит отриманий, продовжується обробка.
o 2xx: Успішні коди – дія була успішно отримана, зрозуміле і оброблено.
o 3xx: Коди перенаправлення – для виконання запиту повинні бути зроблені подальші дії.
o 4xx: Коди помилок клієнта – запит має поганий синтаксис або не може бути виконаний.
o 5xx: Коди помилок сервера – сервер не в змозі виконати допустимий запит.
Конкретні значення числових кодів стану, визначених у HTTP/1.1, і зразковий набір відповідних пояснювальних фраз (Reason-Phrase) наводяться нижче. Пояснювальні фрази (Reason-Phrase), перераховані тут є рекомендованими, але можуть бути замінені на еквівалентні без впливу на протокол.
Status-Code = “100”; Продовжувати, Continue | “101”; Перемикання протоколів,
; Switching Protocols
| “200” ; OK | “201”; Створений, Created | “202”; Прийнято, Accepted | “203”, Не авторська інформація,
; Non-Authoritative Information | “204”; Немає вмісту, No Content | “205”; Скинути вміст, Reset
; Content | “206”; Часткове вміст, Partial
; Content | “300”; Множинний вибір, Multiple
; Choices | “301”; Постійно перенесений, Moved
; Permanently | “302”; Тимчасово переміщено, Moved
; Temporarily | “303”; Дивитися інший, See Other | “304”, Не модифікований, Not Modified | “305”; Використовуйте проксі-сервер, Use
; Proxy | “400”; Зіпсований Запит, Bad Request | “401”; Несанкціоновано, Unauthorized | “402”; Потрібен оплата, Payment
; Required | “403”; Заборонено, Forbidden | “404”, Не знайдений, Not Found | “405”; Метод не дозволений, Method Not
; Allowed | “406”, Не прийнятний, Not Acceptable | “407”; Требуется встановлення ; Справжності через проксі-сервер,
; Proxy Authentication Required | “408”; закінчено час очікування запиту,
; Request Timeout | “409”; Конфлікт, Conflict | “410”; Вилучений, Gone | “411”; Требуется довжина, Length Required | “412”; Передумови невірно,
; Precondition Failed | “413”; Об’єкт запиту занадто великий,
; Request Entity Too Large | “414”; URI запиту занадто довгий,
; Request-URI Too Long | “415”; Непідтримуваний медіа тип,
; Unsupported Media Type | “500”; Внутрішня помилка сервера,
; Internal Server Error | “501”, Не реалізовано, Not Implemented | “502”; Помилка шлюзу, Bad Gateway | “503”; Сервіс недоступний, Service
; Unavailable | “504”; закінчено час очікування від шлюзу,
; Gateway Timeout | “505”, Не підтримувана версія HTTP,
; HTTP Version Not Supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *
Коди стану HTTP розширюваності. HTTP додатків не потрібно розуміти значення всіх зареєстрованих кодів стану, хоча таке розуміння дуже бажано. Однак, додатки ПОВИННІ розуміти клас будь-якого коду стану, який позначається перша цифрою, і обробляти будь нерозпізнаний відповідь як еквівалентний коду стану x00 цього класу, за винятком тих випадків, коли нерозпізнаний відповідь НЕ ПОВИНЕН кешуватися. Наприклад, якщо клієнтом отриманий і не був розпізнаний код стану 431, то він може безпечно вважати, що в запиті щось було неправильно і обробляти відповідь, як якщо б був отриманий код стану 400. У таких випадках агентам користувача СЛІД представити користувачеві об’єкт, повернутий у відповіді, так як цей об’єкт, ймовірно, включає читабельну для людини інформацію, яка пояснює незвичайне стан.

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


Поля заголовка відповіді (response-header fields) дозволяють серверу передавати додаткову інформацію, що стосується відповіді, яка не може бути поміщена в рядок стану Status-Line. Ці поля заголовка дають інформацію про сервер і про подальший доступ до ресурсу, вказаному цим Request-URI.
response-header = Age; Розділ 14.6 | Location; Розділ 14.30 | Proxy-Authenticate; Розділ 14.33 | Public; Розділ 14.35 | Retry-After; Розділ 14.38 | Server; Розділ 14.39 | Vary; Розділ 14.43 | Warning; Розділ 14.45 | WWW-Authenticate; Розділ 14.46
Імена полів заголовка відповіді (Response-header) можуть бути надійно розширені тільки в поєднанні зі зміною версії протоколу. Однак, нові або експериментальні поля заголовка можуть отримати семантику полів заголовка відповіді (Response-header), якщо всі сторони з’єднання розпізнають їх як поля заголовка відповіді (Response-header). Нерозпізнані поля заголовка обробляються як поля заголовка об’єкта (entity-header).
Безліч імен полів заголовка відповіді (Response-header) може бути надійно розширено тільки в комбінації зі зміною версії протоколу. Однак, нові або експериментальні поля заголовка з семантикою полів заголовка відповіді МОЖУТЬ бути додані якщо всі учасники з’єднання розпізнають їх як поля заголовка відповіді. Нерозпізнані поля заголовка обробляються як поля заголовка об’єкта.

7 Об’єкт (Entity).


Повідомлення запитів і відповідей МОЖУТЬ передати об’єкт, якщо інше не встановлено методом запиту або кодом стану відповіді. Об’єкт складається з полів заголовка об’єкта (entity-header) і тіла об’єкта (Entity-body), хоча деякі відповіді можуть включати тільки заголовки об’єкта (entity-headers).
Цей розділ відноситься як до відправника, так і до одержувача, то є до клієнта або сервера, в залежності від того, хто посилає, а хто отримує об’єкт.

7.1 Поля заголовка об’єкта.


Поля заголовка об’єкта (Entity-header fields) визначають опціональну метаінформацію про тіло об’єкта або, якщо тіло не присутній, щодо ресурсу, ідентифікованого запитом.
entity-header = Allow; Розділ 14.7 | Content-Base; Розділ 14.11 | Content-Encoding; Розділ 14.12 | Content-Language; Розділ 14.13 | Content-Length; Розділ 14.14 | Content-Location; Розділ 14.15 | Content-MD5; ​​Розділ 14.16 | Content-Range; Розділ 14.17 | Content-Type; Розділ 14.18 | ETag; Розділ 14.20 | Expires; Розділ 14.21 | Last-Modified; Розділ 14.29
| extension-header
extension-header = message-header
Механізм розширення полів заголовка дозволяє вводити додаткові поля заголовка об’єкта (entity-header fields) не змінюючи протокол, але ці поля не можуть вважатися розпізнаваними одержувачем. Нерозпізнані поля заголовка одержувачу СЛІД ігнорувати, а проксі-сервера пересилати без змін.

7.2 Тіло об’єкта.


Тіло об’єкта (якщо воно є) надсилається з HTTP запитом або відповіддю і має формат і кодування, яке визначається полями заголовка об’єкта (entity-header fields).
entity-body = *OCTET
Тіло об’єкта (entity-body) представлено в повідомленні тільки тоді, коли присутній тіло повідомлення (message-body), як описано в розділі 4.3. Тіло об’єкта (entity-body) виходить з тіла повідомлення (message-body), декодуванням кодування передачі, зазначеного в поле Transfer-Encoding, і яке може бути застосовано для гарантування безпечної і правильної передачі повідомлення.

7.2.1 Тип (Type).


Коли тіло об’єкта (entity-body) включено до повідомлення, тип даних цього тіла визначається полями заголовка Content-Type і Content-Encoding. Вони визначають дворівневу упорядковану модель кодування:
entity-body := Content-Encoding( Content-Type( data ) )
Тип вмісту (Content-Type) визначає медіа тип основних даних. Кодування вмісту (Content-Encoding) може використовуватися для вказівки будь-якого додаткового кодування вмісту, застосованого до даних (зазвичай з метою стиснення даних). Кодування вмісту (Content-Encoding) є властивістю запитаного ресурсу. За замовчуванням ніякого кодування не задано.
Будь HTTP/1.1 повідомлення, що містить тіло об’єкта (entity-body) СЛІД включати поле заголовка Content-Type, що визначає медіа тип цього тіла. В тому і тільки в тому випадку, коли медіа тип не представлений полем Content-Type, одержувач МОЖЕ спробувати припустити медіа тип, перевіряючи вміст і / або розширення (Розширення) в імені URL, використовуваного для ідентифікації ресурсу. Якщо медіа тип залишається нерозпізнаним, одержувачу СЛІД обробляти його як тип “application / octet-stream”.

7.2.2 Довжина (Length).


Довжина тіла об’єкта (entity-body) – це довжина тіла повідомлення (Message-body), отриманого після декодування всіх кодувань передачі. Розділ 4.4 визначає як обчислюється довжина тіла повідомлення (message-body).

8 Сполуки (Connections).


8.1 Постійні з’єднання (Persistent Connections).


8.1.1 Мета.


До постійних з’єднань для запиту кожного URL встановлювалося окреме TCP з’єднання, що збільшувало навантаження на HTTP сервера і викликало завантаження Інтернету. Використання вбудованих зображень і інших пов’язаних даних часто вимагає від клієнта робити кілька запитів до одного сервера за короткий проміжок часу. Дослідження проблем ефективності такого рішення доступні в [30] [27]; аналіз і результати реалізації прототипу знаходяться в [26].
Постійні HTTP сполуки мають ряд переваг:
o Відкриття та закриття меншої кількості TCP з’єднань економить час центрального процесора і пам’ять, використовувану для керуючих блоків протоколу TCP.
o HTTP запити та відповіді може бути конвейерізовать в з’єднанні. Конвеєрна обробка дозволяє клієнту робити безліч запитів не чекаючи відповіді на кожен, отже, одиночне TCP з’єднання, використання якого набагато більш ефективно, втрачає менше часу.
o Завантаження мережі зменшується із зменшенням числа пакетів, викликаних відкриттям TCP з’єднань, і, отже, дає протоколу TCP достатній час для визначення стану завантаження мережі.
o HTTP може розвиватися більш елегантно; оскільки помилки можуть повідомлятися без закриття TCP з’єднання в якості штрафу. Клієнти, що використовують майбутні версії HTTP могли б оптимістично пробувати нові можливості, але при зв’язку зі старим сервером, повторювати запит, використовуючи стару семантику після повідомлення про помилку.
HTTP реалізаціям СЛІД реалізовувати постійні з’єднання.

8.1.2 Загальний опис.


Значне відміну HTTP/1.1 від більш ранніх версій HTTP складається в тому, що постійні сполуки є заданим за умовчанням поведінкою будь-якого HTTP з’єднання. Тобто якщо не позначено іншого, клієнт може вважати, що сервер підтримає постійне з’єднання.
Постійні з’єднання забезпечують механізм, згідно з яким клієнт і сервер можуть повідомити про розрив TCP з’єднання. Це сигналізується за допомогою використання поля заголовка Connection. При отриманні повідомлення про розрив з’єднання клієнт НЕ ПОВИНЕН посилати більше запитів по цьому з’єднанню.

8.1.2.1 Обговорення (Negotiation).


HTTP/1.1 сервер МОЖЕ вважати, що HTTP/1.1 клієнт не припускає підтримувати постійне з’єднання, якщо посланий в запиті заголовок Connection містить лексему з’єднання (Connection-token) “close”. Якщо сервер вирішує закрити з’єднання негайно після посилки відповіді, то йому СЛІД послати заголовок Connection, який містить лексему з’єднання (connection-token)
“close”.
HTTP/1.1 клієнт МОЖЕ очікувати, що з’єднання залишиться відкритим, але повинен вирішити чи залишати його відкритим на підставі того, чи містить відповідь сервера заголовок Connection з лексемою з’єднання “close”. У випадку, якщо клієнт не хоче підтримувати з’єднання для подальших запитів, йому СЛІД послати заголовок Connection, що містить лексему з’єднання “close”.
Якщо клієнт або сервер посилає лексему закриття з’єднання “Close” в заголовку Connection, то запит стає останнім в з’єднанні.
Клієнтам і серверів НЕ СЛІД вважати, що постійне з’єднання підтримується HTTP версіями, меншими ніж 1.1, якщо це не вказано явно. Дивіться розділ 19.7.1 з більш детальною інформацією про забезпечення сумісності з HTTP/1.0 клієнтами.
Щоб з’єднання залишалося постійним, всі повідомлення, передаються по ньому повинні мати самовизначення (self-defined) довжину повідомлення (тобто, не обумовлену закриттям з’єднання), як описано в розділі 4.4.

8.1.2.2 Конвеєрна обробка (Pipelining).


Клієнт, який підтримує постійні з’єднання МОЖЕ “Зробити конвеєрну обробку” запитів (тобто, посилати декілька запитів не чекаючи відповіді на кожен). Сервер ПОВИНЕН послати відповіді на ці запити в тому ж самому порядку, в якому були отримані запити.
Клієнти, які підтримують постійні з’єднання і виробляють конвеєрну обробку негайно після встановлення з’єднання, ПОВИННІ бути готові повторити з’єднання, якщо перша спроба конвеєрної обробки дала збій. Якщо клієнт робить такий повтор, він НЕ МАЄ робити конвеєрну обробку перш, ніж дізнається, що з’єднання постійне. Клієнти ПОВИННІ також бути готові знову послати запити, якщо сервер закриває з’єднання перед посилкою всіх відповідних відповідей.

8.1.3 Проксі-сервера (Proxy Servers).


Дуже важливо, щоб проксі-сервера правильно виконували властивості полів заголовка Connection, як визначено в 14.2.1.
Проксі-сервер ПОВИНЕН повідомляти про постійні з’єднаннях окремо своїм клієнтам і окремо початковим серверів (або іншим проксі-серверів), які з ним з’єднані. Кожне постійне з’єднання застосовується тільки до однієї транспортного зв’язку.
Проксі-сервер НЕ ПОВИНЕН встановлювати постійне з’єднання з HTTP/1.0 клієнтом.

8.1.4 Практичні Угоди про використання (Practical Considerations).


Сервера зазвичай мають деяке значення часу очікування та якого вони не підтримують неактивна сполука. Проксі-сервера можуть робити це значення більш високим, оскільки, ймовірно, клієнт зробить більшу кількість з’єднань через цей же сервер. Використання постійних з’єднань не вводить ніяких обмежень на тривалість цього часу очікування як для клієнта, так і для сервера.
Коли у клієнта або сервера минув час очікування, йому СЛІД провести витончене закриття транспортного з’єднання. Як клієнтам, так і серверів СЛІД постійно спостерігати за одною стороною на предмет закриття з’єднання, і відповідно відповідати. Якщо клієнт або сервер не виявляє закриття з’єднання іншою стороною відразу, то це викликає не виправдану витрату ресурсів мережі.
Клієнт, сервер, або проксі-сервер МОЖУТЬ закрити транспортний з’єднання в будь-який час. Наприклад, клієнт МОЖЕ почати посилати новий запит в той час, коли сервер вирішує закрити “Недіюче” з’єднання. З точки зору сервера, з’єднання закривається, в той час як воно було неактивно, але з точки зору клієнта, запит відбувся.
Це означає, що клієнти, сервери, і проксі-сервери ПОВИННІ бути в змозі обробляти асинхронні події закриття. Програмного забезпечення клієнта СЛІД знову відкрити транспортне сполучення і повторно передати перерваний запит без ? взаємодії з користувачем, оскільки метод запиту idempotent (дивіться розділ 9.1.2); інші методи НЕ ПОВИННІ бути повторені автоматично, хоча агенти користувача МОЖУТЬ запропонувати оператору вибір повторювати запит, чи ні.
Однак це автоматичне повторення НЕ СЛІД робити, якщо збій відбувається вже у другому запиті.
Серверів завжди СЛІД відповідати на принаймні на один запит в з’єднанні, якщо це можливо. Серверів НЕ СЛІД розривати з’єднання в середині передачі відповіді, якщо не передбачається мережний або клієнтський відмову.
Клієнтам, які використовують постійні з’єднання, СЛІД обмежити число одночасних з’єднань, які вони встановлюють за даними сервером. Однокористувальницькому клієнту СЛІД встановлювати максимум 2 з’єднання з будь-яким сервером або проксі-сервером. Проксі-серверу СЛІД обмежитися 2 * N поєднанні з іншими серверами або проксі-серверами, де N – число одночасно активних користувачів. Ці керівні принципи призначені для зменшення часу HTTP відповіді та уникнення надмірної завантаження Інтернету або інших мереж.

8.2 Вимоги до передачі повідомлень.


Загальні вимоги:
o HTTP/1.1 серверам СЛІД підтримувати постійні з’єднання і використовувати механізми управління потоком даних TCP в цілях зменшення тимчасових перевантажень, замість закриття з’єднань, які, як очікується, можуть бути повторно використані клієнтами. Остання методика може посилювати мережеву завантаження.
o HTTP/1.1 (або більш пізнім) клієнтам, посилає тіло повідомлення (message-body) СЛІД контролювати мережеве з’єднання на предмет помилок під час передачі запиту. Якщо клієнт виявляє помилку, йому слід негайно припинити передачу тіла повідомлення. Якщо тіло надсилається з використанням кодування “по шматках” (“chunked”, розділ 3.6), то шматок нульової довжини, і порожній завершувач МОЖУТЬ використовуватися для індикації передчасного кінця повідомлення. Якщо тілу передував заголовок Content-Length, клієнт ПОВИНЕН закрити з’єднання.
o HTTP/1.1 (або більш пізній) клієнт ПОВИНЕН бути готовий прийняти відповідь з кодом стану 100 (Продовжувати, Continue), попередній основному відповіді.
o HTTP/1.1 (або більш пізній) сервер, який отримує запит від HTTP/1.0 (або більш раннього) клієнта НЕ ПОВИНЕН передати відповідь з кодом стану 100 (Продовжувати, Continue); йому СЛІД або чекати поки запит буде виконаний звичайним чином (тобто без використання перерваного запиту), або передчасно закрити з’єднання.
Після отримання методу, підлеглого цим вимогам, від HTTP/1.1 (Або більш пізнього) клієнта, HTTP/1.1 (або більш пізній) сервер ПОВИНЕН або відповісти кодом стану 100 (Продовжувати, Continue) і продовжувати читання вхідного потоку, або відповісти помилковим кодом стану. Якщо сервер відповів помилковим кодом стану, то він МОЖЕ або закрити транспортне сполучення (TCP), або продовжувати читати і відкидати частину запиту. Він НЕ МАЄ виконувати запитаний метод, якщо повернув код стану помилки.
Клієнтам СЛІД пам’ятати номер версії HTTP, використовуваної сервером по крайней мере в останній раз, якщо HTTP/1.1 клієнт зустрічав HTTP/1.1 або пізніший відповідь від сервера, і бачить закриття з’єднання перед отриманням будь-якого коду стану від сервера, клієнту СЛІД повторити запит без взаємодії з ? користувачем, оскільки метод запиту idempotent (дивіться розділ 9.1.2); інші методи НЕ ПОВИННІ бути повторені автоматично, хоча агенти користувача МОЖУТЬ запропонувати оператору вибір повторювати запит, чи ні. Якщо клієнт повторює запит, то він
o ПОВИНЕН спочатку послати поля заголовка запиту, а потім
o ПОВИНЕН очікувати відповіді сервера з кодом 100 (Продовжувати, Continue), а потім продовжувати, або з кодом стану помилки.
Якщо HTTP/1.1 клієнт не зустрічав відповіді сервера версії HTTP/1.1 або більш пізньої, то йому слід вважати, що сервер реалізує HTTP/1.0 або більш старий протокол і не використовувати відповіді з кодом стану 100 (Продовжувати, Continue). Якщо в такій ситуації клієнт бачить закриття з’єднання перед отриманням будь-якого відповіді з кодом стану від сервера, то йому СЛІД повторити запит. Якщо клієнт повторює запит до цього HTTP/1.0 серверу, то ? він повинен використовувати наступний “binary exponential backoff” алгоритм, щоб бути впевненим в отриманні надійного відповіді:
1. Ініціалізувати нове з’єднання з сервером.
2. Передати заголовки запиту (request-headers).
3. Ініціалізувати змінну R зразковим часом передачі інформації на сервер і назад (наприклад на підставі часу встановлення з’єднання), або постійним значення в 5 секунд, якщо час передачі не доступно.
4. Обчислити T = R * (2 ** N), де N – число попередніх повторів цього запиту.
5. Або дочекатися від сервера відповіді з кодом помилки, або просто почекати T секунд (дивлячись що відбудеться раніше).
6. Якщо відповіді з кодом помилки не отримано, після T секунд передати тіло запиту.
7. Якщо клієнт виявляє, що з’єднання було закрито передчасно, то йому потрібно повторювати починаючи з кроку 1, поки запит не буде прийнятий, або поки не буде отриманий помилковий відповідь, або поки у користувача не скінчиться терпіння і він не завершить процес повторення.
Незалежно від того, яка версія HTTP реалізована сервером, якщо клієнт отримує помилковий код стану, то він
o НЕ ПОВИНЕН продовжувати і
o ПОВИНЕН закрити з’єднання, якщо він не завершив посилку повідомлення.
HTTP/1.1 (або більш пізнього) клієнту, який виявляє закриття з’єднання після отримання відповіді з кодом стану 100 (Продовжувати, Continue), але до отримання відповіді з іншим кодом стану, СЛІД повторити запит, але вже не чекати відповіді з кодом стану 100 (Продовжувати, Continue) (але він МОЖЕ зробити так, якщо це спрощує реалізацію).

9 Визначення методів (Method Definitions).


Набір загальних методів для HTTP/1.1 наводиться нижче. Хоча цей набір може бути розширений, не можна вважати, що додаткові методи мають одіннаковом семантику, якщо вони є розширеннями різних клієнтів і серверів.
Поле заголовка запиту Host (розділ 14.23) ПОВИННО супроводжувати все HTTP/1.1 запити.
? 9.1 Безпечні і Idempotent методи.

9.1.1 Безпечні методи.


Програмістам слід розуміти, що програмне забезпечення при взаємодії з Інтернетом являє користувача, і програмі слід інформувати користувача про будь-які дії, які він може зробити, але які можуть мати непередбачуване значення для нього або інших осіб.
Зокрема було прийнято угоду, що методи GET і HEAD ніколи не повинні мати іншого значення, крім завантаження. Ці методи слід розглядати як “безпечні”. Це дозволяє агентам користувача представляти інші методи, такі як POST, PUT і DELETE, таким чином, щоб користувач був проінформований про те, що він запитує виконання потенційно небезпечного діяння.
Природно, не можливо гарантувати, що сервер не генерує побічні ефекти в результаті виконання запиту GET; фактично, деякі динамічні ресурси містять таку можливість. Важливе відмінність тут в тому, що не користувач запитує побічні ефекти, і, отже, користувач не може нести відповідальність за них.
? 9.1.2 Idempotent методи.
Методи можуть також мати властивість “idempotence” в тому сенсі, що побічні ефекти від N> 0 ідентичних запитів такі ж, як від одиночного запиту (за виключення помилок і проблем застарівання). Методи GET, HEAD, PUT і DELETE володіють даними властивістю.

9.2 OPTIONS.


Метод OPTIONS представляє запит інформації про опції з’єднання, доступних в ланцюжку запитів / відповідей, ідентифікованої запитуваною URI (Request-URI). Цей метод дозволяє клієнту визначати опції та / або вимоги, пов’язані з ресурсом, або можливостями сервера, але не виробляючи ніяких дій над ресурсом і не ініціюючи його завантаження.
Якщо відповідь сервера – це не повідомлення про помилку, то відповідь НЕ ПОВИНЕН містити іншої інформації об’єкта, крім тієї, яку можна розглядати як опції з’єднання (наприклад Allow – можна розглядати як опцію з’єднання, а Content-Type – ні). Відповіді на цей метод не кешуються.
Якщо запитуваний URI (Request-URI) – зірочка (“*”), то запит OPTIONS призначений для звернення до сервера в цілому. Якщо код стану у відповіді – 200, то відповіді СЛІД містити будь-які поля заголовка, які вказують опціональні можливості, реалізовані сервером (наприклад, Public), включаючи будь-які розширення, не визначені цією специфікацією, на додаток до відповідних загальним полям або полям заголовка відповіді (response-header). Як описано в розділі 5.1.2, запит “OPTIONS *” може бути застосований через проксі-сервер з визначенням адресується сервера в запитуваній URI (Request-URI) з порожнім шляхом.
Якщо запитуваний URI (Request-URI) не зірочка (“*”), то запит OPTIONS застосовується до опцій, які доступні при з’єднанні з зазначеним ресурсом. Якщо код стану відповіді – 200, то відповіді СЛІД містити будь-які поля заголовка, які вказують опціональні можливості, реалізовані сервером і застосовуються до вказаною ресурсу (наприклад, Allow), включаючи будь-які розширення, не визначені цією специфікацією, на додаток до відповідних загальним полям або полям заголовка відповіді (response-header). Якщо запит OPTIONS передається через проксі-сервер, то останній редагує відповідь, виключаючи ті опції, які не передбачені можливості цього проксі-сервера.

9.3 GET.


Метод GET дозволяє отримувати будь-яку інформацію (у формі об’єкта), ідентифіковану запитуваною URI (Request-URI). Якщо запитуваний URI (Request-URI) звертається до процесу, проводить дані, то в якості об’єкта відповіді повинні бути повернуті вироблені дані, а не вихідний текст процесу, якщо сам процес не виводить вихідний текст.
Різниться “умовний GET” (“conditional GET”), при якому повідомлення запиту містить поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, або If-Range. Умовний метод GET запитує передачу об’єкта, тільки якщо він задовольняє умовам, описаним в умовних полях заголовка. Умовний метод GET призначений для зменшення непотрібної завантаження мережі, і дозволяє оновлювати кешовані об’єкти без використання кількох запитів або пересилання даних, уже збережених клієнтом.
Розрізняється також “частковий GET” (“partial GET”), при якому повідомлення запиту містить поле заголовка Range. Частковий GET запитує передачу тільки частини об’єкта, як описано в розділі 14.36. Частковий метод GET призначений для зменшення непотрібною завантаження мережі, і дозволяє збирати об’єкти з частин, без передачі частин даних, уже збережених клієнтом.
Відповідь на запит GET кешіруем тоді і тільки тоді, коли він відповідає вимогам HTTP кешування, описаним в розділі 13.

9.4 HEAD.


Метод HEAD ідентичний GET, за винятком того, що сервер НЕ ПОВИНЕН повертати у відповіді тіло повідомлення (message-body). Метаінформації, що міститься в HTTP заголовках відповіді на запит HEAD СЛІД бути ідентичною інформації, що подається у відповідь на запит GET. Цей метод може використовуватися для отримання метаінформації про об’єкт запиту без безпосередньої пересилки тіла об’єкта (entity-body). Цей метод часто використовується для тестування гіпертекстових зв’язків з метою перевірки правильності, досяжності, і часу модифікації.
Відповідь на запит HEAD може бути Кешована в тому сенсі, що інформація, що міститься у відповіді може використовуватися для модіфіцікаціі попередньо кешированной об’єкта з цього ресурсу. Якщо нові значення поля вказують, що Кешована об’єкт відрізняється від поточного об’єкта (за такими параметрами, як Content-Length, Content-MD5, ETag або Last-Modified), то кеш ПОВИНЕН обробляти вміст як прострочене.

9.5 POST.


Метод POST використовується для запиту, при якому адресується сервер приймає об’єкт, включений до запиту, як нове підпорядкування ресурсу, ідентифікованого запитуваною URI (Request-URI) в рядку запиту (Request-Line). POST розроблений для того, щоб загальним методом реалізувати наступні функції:
o Анотація існуючих ресурсів;
o Реєстрація повідомлення на електронній дошці оголошень (Bulletin board), в конференції новин (newsgroup), списку розсилки (mailing list), або подібної групи статей;
o Передача блоку даних, наприклад результат введення у формі, процесу обробки;
o Розширення бази даних за допомогою конкатенірующей операції
(append operation).
Фактично функція, виконувана методом POST, визначається сервером і звичайно залежить від запитуваної URI (Request-URI). Об’єкт, який передається методом POST, ставиться до цього URI таким же чином, як файл відноситься до каталогу, в якому він знаходиться, стаття відноситься до конференції новин (newsgroup), в якій вона зареєстрована, а запис відноситься до бази даних.
Дія, що виконується методом POST може не давати в якості результату ресурс, який можна було б ідентифікувати URI. В цьому випадку, залежно від того, чи включає відповідь об’єкт, описує результат, чи ні, код стану у відповіді може бути як 200 (OK), так і 204 (Немає вмісту, No Content).
Якщо ресурс був створений на первинному сервері, відповіді СЛІД містити код стану 201 (Створений, Created) і включати об’єкт, який описує стан запиту і посилається на новий ресурс, а також заголовок Location (дивіться розділ 14.30).
Відповіді на цей метод не Кешована, якщо відповідь не містить відповідні поля заголовка Cache-Control або Expires. Однак, відповідь з кодом стану 303 (Дивитися інший, See Other) може використовуватися для перенаправлення агента користувача для завантаження кешувального ресурсу.
Запити POST повинні відповідати вимогам передачі повідомлення, викладеним в розділі 8.2.

9.6 PUT.


Запити з методом PUT, що містять об’єкт, зберігаються під запитуваною URI (Request-URI). Якщо Request-URI звертається до вже існуючого ресурсу, включений об’єкт СЛІД розглядати як модифіковану версію об’єкту, що знаходиться на початковому сервері. Якщо Request-URI не вказує на існуючий ресурс, і може інтерпретуватися агентом користувача як новий ресурс для запитів, початковий сервер може створити ресурс із даним URI. Якщо новий ресурс створений, то первісний сервер ПОВИНЕН повідомити агенту користувача про це за допомогою відповіді з кодом стану 201 (Створений, Created). Якщо існуючий ресурс модифікований, то для вказівки успішного завершення запиту СЛІД послати відповідь з кодом стану або 200 (OK), або 204 (Немає вмісту, No Content). Якщо ресурс не може бути створений або змінений для запитуваної URI (Request-URI), то СЛІД послати відповідь, відображає характер проблеми. Одержувач об’єкта НЕ МАЄ ігнорувати заголовків Content-* (наприклад Content-Range), яких не розуміє або не реалізує, а ПОВИНЕН в даному випадку повернути відповідь з кодом стану 501 (Не реалізовано, Not
Implemented).
Якщо запит передається через кеш і запитуваний URI (Request-URI) ідентифікує один або кілька кешованих в даний час об’єктів, то входження в кеш цих об’єктів повинні оброблятися як прострочені. Відповіді на цей метод не Кешована.
Фундаментальне розходження між POST і PUT запитами, відображено в різному значенні запитуваної URI (Request-URI). URI в запиті POST ідентифікує ресурс, який обробляє включений об’єкт. Цим ресурсом може бути процес, який приймає дані, шлюз до деякого іншого протоколу, або окремий об’єкт, який приймає анотації (accepts annotations). Навпаки, URI в запиті PUT ідентифікує об’єкт, включений до запиту – агент користувача призначає даний URI включеному ресурсу, а сервер НЕ ПОВИНЕН намагатися застосувати запит до деякого іншого ресурсу. Якщо сервер бажає застосувати запит до іншого URI, він ПОВИНЕН послати відповідь з кодом 301 (переміщений постійно, Moved Permanently); агент користувача МОЖЕ потім прийняти власне рішення щодо перепризначення запиту.
Одиночний ресурс МОЖЕ бути ідентифікований кількома різними URI. Наприклад, стаття може мати URI ідентифікує “поточну версію “, який відмінний від URI, що ідентифікує кожну специфічну версію. В цьому випадку, запит PUT на загальний URI може відбитися (may result) на кількох інших URI, визначених сервером походження.
HTTP/1.1 не визначає яким чином метод PUT впливає на стан первинного сервера.
Запити PUT повинні підкорятися вимогам передачі повідомлень, викладеним в розділі 8.2.

9.7 DELETE.


Метод DELETE запитує початковий сервер про видалення ресурсу, ідентифікованого запитуваною URI (Request-URI). Цей метод МОЖЕ бути скасовано людським втручанням (або іншими засобами) на первинному сервері. Клієнту не можна гарантувати, що операція була виконана, навіть якщо код стану, повернутий первісним сервером вказує на те, що дія була завершено успішно. Однак, серверу НЕ СЛІД відповідати про успішне виконання, якщо під час відповіді він передбачає видалити ресурс або перемістити його в недоступне положення.
Успішному відповіді СЛІД мати код стану 200 (OK), якщо відповідь включає об’єкт, що описує стан, або мати код стану 202 (Прийнято, Accepted), якщо дія ще не було зроблено, або мати код стану 204 (Немає вмісту, No Content), якщо відповідь повідомляє про успіх (OK), але не містить об’єкта.
Якщо запит передається через кеш і запитуваний URI (Request-URI) ідентифікує один або кілька кешованих в даний час об’єктів, то входження їх повинні оброблятися як прострочені. Відповіді на цей метод не Кешована.

9.8 TRACE.


Метод TRACE використовується для виклику віддаленого повернення повідомлення запиту на рівні програми. Кінцевого одержувача запиту СЛІД відобразити отримане повідомлення назад клієнтові як тіло об’єкта відповіді з кодом стану 200 (OK). Кінцевим одержувачем є або сервер походження, або перший проксі-сервер, або перший шлюз, який отримав нульове значення (0) в поле Max-Forwards в запиті (див. розділ 14.31). Запит TRACE НЕ ПОВИНЕН містити об’єкта.
TRACE дозволяє клієнтові бачити, що виходить на іншому кінці ланцюжка запитів і використовувати ці дані для тестування або діагностичної інформації. Значення поля заголовка Via (розділ 14.44) представляє особливий інтерес, тому що воно діє як слід ланцюжка запитів. Використання поля заголовка Max-Forwards дозволяє клієнту обмежувати довжину ланцюжка запитів, що є корисним при тестуванні нескінченних циклів в ланцюжку проксі-серверів, що надсилають повідомлення.
Якщо запит успішно виконано, то відповіді СЛІД містити всі повідомлення запиту в тілі об’єкта (entity-body), а Content-Type слід бути рівним “message / http”. Відповіді на цей метод НЕ ПОВИННІ кешуватися.

10 Опис кодів стану (Status Code Definitions).


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

10.1 1xx – Інформаційні коди.


Цей клас кодів стану вказує попередній (тимчасовий) відповідь, що складається тільки з рядка стану (Status-Line) і опціональних заголовків, і завершується порожнім рядком. Так як HTTP/1.0 не визначав ніяких 1xx кодів стану, сервери НЕ ПОВИННІ посилати 1xx відповіді HTTP/1.0 клієнтам, за винятком експериментальних умов.

10.1.1 100 Продовжувати, Continue.


Клієнт може продовжувати запит. Цей проміжний відповідь використовується, для того, щоб повідомити клієнта, що початкова частину запиту було отримано і ще не відкинута сервером. Клієнту СЛІД продовжити посилку залишилися даних запиту або, якщо запит вже був виконаний, ігнорувати цю відповідь. Сервер ПОВИНЕН послати заключний відповідь після того, як запит буде виконаний.

10.1.2 101 Перемикання протоколів, Switching Protocols


Сервер розуміє і бажає виконати запит клієнта, якщо протокол прикладної програми в цьому з’єднанні буде змінений на той, який вказаний в полі заголовка повідомлення Upgrade (розділ 14.41). Сервер перемкне протокол на той, що визначений в поле заголовка відповіді Upgrade безпосередньо після порожній рядки, яка завершує відповідь з кодом стану 101.
Протокол повинен бути переключено тільки тоді, коли це принесе вигоду. Наприклад, перемикання на більш нову версію HTTP вигідно по порівняння з використанням більш старих версій, а перемикання на синхронний протокол реального часу може бути вигідно при надання ресурсів, які використовують такі можливості.

10.2 2xx – Успішні коди.


Цей клас кодів стану вказує, що запит клієнта був успішно отриманий, зрозумілий, і прийнятий.

10.2.1 200 OK.


Запит був вдало виконаний. Інформація, яка повертається з відповіддю залежить від методу, що використовується в запиті. Наприклад:
GET у відповіді представлений об’єкт, відповідний запрошенням ресурсу;
HEAD у відповіді представлені поля заголовка об’єкта (Entity-header), відповідні запрошенням ресурсу. Тіло повідомлення (message-body) відсутня;
POST у відповіді представлено опис об’єкта або міститься результат дії;
TRACE у відповіді представлений об’єкт, що містить повідомлення запиту, отриманого кінцевим сервером.

10.2.2 201 Створений, Created.


Запит був виконаний і в результаті був створений новий ресурс. Новий створений ресурс може бути викликаний по URI (одному або декільком), повернутим в об’єкті відповіді; найбільш специфічний URL для ресурсу віддається в поле заголовка Location. Початковий сервер ПОВИНЕН створити ресурс перед поверненням коду стану 201. Якщо дія не може бути виконано негайно, сервер повинен повернути відповідь з кодом стану 202 (Прийнято, Accepted) замість
201.

10.2.3 202 Прийнято, Accepted.


Запит був прийнятий для обробки, але обробка не була завершена. В кінцевому рахунку запит МОЖЕ бути, а може і не бути виконано, оскільки він МОЖЕ бути відкинутий при фактичній обробці. Не має ніякої можливості вторинної посилки коду стану від асинхронної операції типу цієї.
Відповідь з кодом стану 202 навмисно уклончів. Мета його полягає в тому, щоб дозволити серверу прийняти запит для деякого іншого процесу (можливо пакетно-орієнтованого процесу, який виконується тільки один раз в день) і не вимагати при цьому, щоб з’єднання агента користувача з сервером зберігалося до завершення процесу. Об’єкту, поверненого з цією відповіддю СЛІД містити індикатор поточного стану запиту і або посилання на монітор стану, або деяку оцінку часу, коли користувач може очікувати завершення виконання запиту.

10.2.4 203 Чи не авторська інформація, Non-Authoritative Information.


Повернена в заголовку об’єкта (entity-header) метаінформація – це не оригінал, доступний на первинному сервері, а документ, зібраний з локальних копій або копій третьої сторони. Представлений документ МОЖЕ бути як підмножиною оригінальної версії, так і містити відомості, що в ній не були представлені. Наприклад, включення локальної анотується інформацію про ресурс МОЖЕ розширити метаінформацію, відому початкового серверу. Використання цього коду стану в відповіді не є необхідним, але може застосовуватися тоді, коли код стану відповіді різниться від 200 (OK).

10.2.5 204 Немає вмісту, No Content.


Сервер виконав запит, але немає ніякої нової інформації, яку можна послати назад. Якщо клієнт – агент користувача, йому НЕ СЛІД змінювати вид документа, який послужив причиною запиту. Ця відповідь призначений насамперед для того, щоб дозволити вводити дані для дій, не змінюючи вид активного документа агента користувача. Відповідь МОЖЕ включати нову метаінформацію в формі заголовків об’єкта (entity-headers), які СЛІД додати до документу, показуваному в даний час агентом користувача.
Відповідь з кодом стану 204 НЕ ПОВИНЕН містити тіла повідомлення, і, таким чином, завжди завершується перший пустий рядок після полів заголовка.

10.2.6 205 Скинути вміст, Reset Content.


Сервер виконав запит, і агенту користувача СЛІД відмінити перегляд документа, який ініціював запит. Ця відповідь призначений насамперед для того, щоб дозволити введення даних, здійснюваний користувачем, з подальшим очищенням форми, в якої зроблений введення, так, щоб користувач міг легко ініціювати наступна дія введення. Відповідь НЕ ПОВИНЕН містити об’єкт.

10.2.7 206 Часткове вміст, Partial Content.


Сервер виконав частковий GET запит ресурсу. Запит повинен містити поле заголовка Range (розділ 14.36), яке вказує бажаний діапазон. Відповідь ПОВИНЕН містити або поле заголовка Content-Range (розділ 14.17), яке вказує діапазон, включений в відповідь, або тип вмісту (Content-Type) повинен бути рівним “Multipart / byteranges”, а поля Content-Range повинні міститися в кожної частини. Якщо “multipart / byteranges” не використовується, поле заголовка Content-Length у відповіді МАЄ відповідати фактичному числу октетів (OCTETs), переданих в тілі повідомлення
(message-body).
Кеш, який не підтримує заголовки Range і Content-Range НЕ ПОВИНЕН кешувати відповіді з кодом стану 206.

10.3 3xx – Перенаправлення.


Цей клас кодів стану вказує, що для виконання запиту агенту користувача необхідно прідпрінять додаткове дію. Необхідний дію МОЖЕ бути виконано агентом користувача без взаємодії з користувачем, тоді і тільки тоді, коли у другому запиті використовується метод GET або HEAD. Агенту користувача НЕ СЛІД автоматично перенаправляти запит більше 5 разів, тому що такі переадресації зазвичай вказують нескінченний цикл.

10.3.1 300 Множинний вибір, Multiple Choices.


Запитаний ресурс має кілька подань, і можна використовувати будь-яке з перерахованих. Кожне уявлення має своє розташування та інформацію для агента з управління діалогом (Розділ 12), представлену таким чином, що користувач (або агент користувача) може вибрати найбільш підходяще подання та перенаправити запит до нього.
Якщо запит був відмінний від HEAD, то відповіді СЛІД містити об’єкт, що включає список характеристик і адрес, з якого користувач або агент користувача може вибрати один найбільш відповідний. Формат об’єкта визначається медіа типом, зазначеним у поле заголовка Content-Type. В залежності від формату та можливостей агента користувача, вибір найбільш підходящого подання може виконуватися автоматично. Однак, ця специфікація не визначає будь-якого стандарту для автоматичного вибору.
Якщо сервер має уявлення за замовчуванням (найбільш переважне), то йому СЛІД включити URL цього подання в поле Location; агенти користувача МОЖУТЬ використовувати значення поля Location для автоматичної переадресації. Ця відповідь є Кешована, якщо не позначено іншого.

10.3.2 301 Постійно перенесений, Moved Permanently.


Запрошенням ресурсу був призначений новий постійний URI, і будь майбутні посилання на цей ресурс СЛІД виконувати, використовуючи один з повернутих URI. Клієнтам з можливостями редагування зв’язків СЛІД автоматично перевизначити посилання на запитуваний URI (Request-URI), використовуючи одну або кілька нових посилань, повернутих сервером в тих місцях, де це можливо. Ця відповідь є Кешована, якщо не позначено іншого.
Якщо новий URI – це розташування, то відповіді СЛІД містити URL в полі Location. Якщо метод запиту був не HEAD, то об’єкту відповіді СЛІД містити коротке гіпертекстове примітка з гіперпосиланням на новий (чи нові) URI.
Якщо код стану 301 був отриманий у відповідь на запит, відмінний від GET або HEAD, агент користувача НЕ ПОВИНЕН автоматично перепризначувати запит, поки немає підтвердження користувача, так як інакше умови запиту зміняться.
Зверніть увагу: При автоматичному перепризначення запиту POST після отримання коду стану 301, деякі існуючі HTTP/1.0 агенти користувача помилково змінять метод запиту на
GET.

10.3.3 302 Тимчасово переміщено, Moved Temporarily.


Запитаний ресурс тимчасово знаходиться під іншим URI. Так як переадресація може бути змінена в будь-який момент, клієнтові СЛІД продовжувати використовувати запитуваний URI (Request-URI) у майбутніх запитах. Кешируємой цієї відповіді залежить тільки від вмісту полів заголовка Cache-Control або Expires (якщо цих полів немає, то відповідь не кешується).
Якщо новий URI – це розташування, то відповіді СЛІД містити URL в полі Location. Якщо метод запиту був не HEAD, то об’єкту відповіді СЛІД містити коротке гіпертекстове примітка з гіперпосиланням на новий (чи нові) URI.
Якщо код стану 302 був отриманий у відповідь на запит, відмінний від GET або HEAD, агент користувача НЕ ПОВИНЕН автоматично перепризначувати запит, поки немає підтвердження користувача, так як інакше умови запиту зміняться.
Зверніть увагу: При автоматичному перепризначення запиту POST після отримання коду стану 302, деякі існуючі HTTP/1.0 агенти користувача помилково змінять метод запиту на
GET.

10.3.4 303 Дивитися інший, See Other.


Відповідь на запит може бути знайдений під іншим URI і його СЛІД запитувати, використовуючи метод GET для цього ресурсу. Цей метод існує передусім для того, щоб виробляти виведення даних активізованого методом POST сценарію, використовуючи перенаправлення агента користувача на зазначений ресурс. Новий URI – це не посилання, що замінює спочатку запитаний ресурс. Відповідь з кодом стану 303 НЕ кешіруем, але відповідь на другий (перепризначений) запит МОЖЕ бути кешуватися.
Якщо новий URI – це розташування, то відповіді СЛІД містити URL в полі Location. Якщо метод запиту був не HEAD, то об’єкту відповіді СЛІД містити коротке гіпертекстове примітка з гіперпосиланням на новий (чи нові) URI.

10.3.5 304 Чи не модифікований, Not Modified.


Якщо клієнт виконав умовний GET запит, і доступ дозволений, але документ не змінився, то серверу СЛІД відповісти, використовуючи цей код стану. Відповідь НЕ ПОВИНЕН містити тіла повідомлення.
Відповідь ПОВИНЕН містити такі поля заголовка:
o Date
o ETag та / або Content-Location, якщо заголовок був би посланий в відповіді з кодом стану 200 на цей же запит
o Expires, Cache-Control, та / або Vary, якщо значення поля (Field-value) може відрізнятися від посланого в будь-якому попередній відповіді для такого ж варіанту
Якщо умовний GET використовує суворе порівняння кеша (strong cache validator) (дивитися розділ 13.3.3), відповіді НЕ СЛІД містити інших заголовків об’єкта (entity-headers). Інакше (тобто, якщо умовний GET використовує слабке порівняння (weak validator)), відповідь НЕ ПОВИНЕН містити інших заголовків об’єкта; це запобігає неузгодженості між кешовані тілами об’єктів (Entity-bodies) і модифікованими заголовками.
Якщо відповідь з кодом стану 304 вказує об’єкт, в даний час не кешированний, то кеш ПОВИНЕН ігнорувати відповідь і повторити запит без умовного вираження.
Якщо кеш використовує отриману відповідь з кодом стану 304 для модіфіцікаціі входження кешу, кеш ПОВИНЕН модифіковані входження так, щоб відобразити будь-які нові значення полів, дані у відповіді.
Відповідь з кодом стану 304 НЕ ПОВИНЕН включати тіла повідомлення (Message-body), і, таким чином, завжди завершується перший порожній рядком після полів заголовка.

10.3.6 305 Використовуйте проксі-сервер, Use Proxy.


Звернення до запрошенням ресурсу МАЄ проводитися через проксі-сервер, зазначений у полі Location. У поле Location вказаний URL проксі-сервера. Очікується, що одержувач повторить запит через проксі-сервер.

10.4 4xx – Коди помилок клієнта.


Клас кодів стану 4xx призначений для випадків, коли клієнт, можливо, припустився помилки. За винятком відповіді на запит HEAD, серверу СЛІД включити об’єкт, що містить пояснення помилковою ситуації, і пояснення, чи є вона тимчасової або постійною. Ці коди стану застосовні до будь-якого методу запиту. Агентам користувача СЛІД показувати користувачеві будь включений об’єкт.
Зверніть увагу: Якщо клієнт посилає дані, то реалізації сервера, що використовує TCP, слід гарантувати, що клієнт підтвердив отримання пакету (ів), що містить відповідь, перш ніж сервер закриє з’єднання. Якщо клієнт продовжує посилати дані серверу після закриття з’єднання, TCP стек сервера пошле пакет скидання (RST) клієнту, а TCP стек клієнта, в свою чергу, може стерти клієнтські непідтверджені вхідні буфера перш, ніж вони будуть прочитані і інтерпретовані додатком HTTP.

10.4.1 400 Зіпсований Запит, Bad Request.


? Запит не може бути зрозумілий сервером через malformed синтаксису. Клієнту НЕ СЛІД повторювати запит без модифікацій.

10.4.2 401 Несанкціоновано, Unauthorized.


Запит вимагає встановлення автентичності користувача. Відповідь ПОВИНЕН включати поле заголовка WWW-Authenticate (розділ 14.46), містить виклик (challenge), що застосовується до запрошенням ресурсу. Клієнт МОЖЕ повторити запит з відповідним полем заголовка Authorization (розділ 14.8). Якщо запит вже включає рекомендації встановлення автентичності (Authorization credentials) в поле Authorization, то відповідь з кодом стану 401 вказує, що в встановлення автентичності цих рекомендацій відмовлено. Якщо відповідь з кодом стану 401 містить той же самий виклик, що і попередній відповідь, а агент користувача вже робив спробу встановлення автентичності принаймні один раз, то СЛІД показати користувачеві об’єкт, який був даний у відповіді, так як ? цей об’єкт МОЖЕ включати relevant діагностичну інформацію. Встановлення автентичності доступу в протоколі HTTP описується в розділі 11.

10.4.3 402 Требуется оплата, Payment Required.


Цей код зарезервований для майбутнього використання.

10.4.4 403 Заборонено, Forbidden.


Сервер зрозумів запит, але відмовляється виконувати його. Встановлення автентичності (Authorization) не допоможе, і запит НЕ ПОВИНЕН бути повторений. Якщо метод запиту не HEAD і сервер бажає вказати, чому запит не був виконаний, йому СЛІД описати причину відмови в об’єкті. Цей код стану зазвичай використовується, коли сервер не бажає вказувати точну причину відмови, або коли ніякої інша відповідь не підходить.

10.4.5 404 Чи не знайдений, Not Found.


Сервер не знайшов нічого, відповідного даному запитуваній URI (Request-URI). Ніяк не повідомляється чи є таке положення тимчасовим або постійним.
Якщо сервер не бажає робити дану інформацію доступною клієнту, то замість цього коду стану може використовуватися код стану 403 (Заборонено, Forbidden). Код стану 410 (Вилучено, Gone) СЛІД використовувати, якщо сервер знає через деякий внутрішньо конфігурується механізм, що старий ресурс більш недоступний, але не знає нового адреси для пересилання.

10.4.6 405 Метод не дозволений, Method Not Allowed.


Метод, визначений в рядку запиту (Request-Line) не дозволено застосовувати для ресурсу, ідентифікованого запитуваною URI (Request-URI). Відповідь ПОВИНЕН включати заголовок Allow, що містить список допустимих методів для запитаного ресурсу.

10.4.7 406 Чи не прийнятний, Not Acceptable.


Ресурс, ідентифікований запитом, має можливості генерації тільки таких об’єктів відповіді, які мають характеристики вмісту (content characteristics), не узгоджуються з заголовками прийому (accept headers), представленими в запиті.
Якщо це був не запит HEAD, то у відповідь СЛІД включити об’єкт, містить список доступних характеристик об’єкта та адреси (Locations), з яких користувач або агент користувача може вибрати найбільш підходящий. Формат об’єкта определеятся медіа типом, представленим в поле заголовка Content-Type. В залежності від формату і можливостей агента користувача, вибір найбільш відповідного варіанту може виконуватися автоматично. Однак, ця специфікація не визначає жодного стандарту для автоматичного вибору.
Зверніть увагу: HTTP/1.1 сервери дозволяють повертати відповіді, які не прийнятні згідно заголовкам прийому (accept headers), представленим у запиті. В деяких випадках, це може бути навіть переважно в порівнянні з посилкою відповіді з кодом стану 406. Агентам користувача непогано б розглядати заголовки надійшов відповіді, щоб визначити, чи є він прийнятним. Якщо відповідь неприпустимий, агенту користувача СЛІД тимчасово зупинитися, щоб отримати більше даних і запитати користувача про подальші дії.

10.4.8 407 Требуется встановлення автентичності через проксі-сервер,


Proxy Authentication Required.
Цей код подібний до коду 401 (Несанкціоновано, Unauthorized), але вказує, що клієнт ПОВИНЕН спочатку встановити свою справжність (Authenticate) проксі-сервера. Проксі-сервер ПОВИНЕН повернути поле заголовка Proxy-Authenticate (розділ 14.33), що містить виклик (challenge), застосовуваний проксі-сервером для запитаного ресурсу. Клієнт МОЖЕ повторити запит з відповідним полем заголовка Proxy-Authorization (розділ 14.34). Встановлення автентичності доступу в протоколі HTTP описується в розділі 11.

10.4.9 408 закінчено час очікування запиту, Request Timeout.


Клієнт не зробив запит протягом часу, який сервер готовий чекати. Клієнт МОЖЕ повторити запит без модифікацій пізніше.

10.4.10 409 Конфлікт, Conflict.


Запит не був виконаний через конфлікт з поточним станом ресурсу. Цей код дозволяється тільки в ситуаціях, коли очікується, що користувач може вирішити конфлікт і повторно передати запит. Тіла відповіді СЛІД містити достатню кількість інформації для користувача, щоб він міг розпізнати джерело конфлікту. В ідеалі, об’єкт відповіді повинен включати достатньо інформації для користувача або агента користувача для вирішення проблеми, а проте це може не бути можливо, та й не потрібно.
Конфлікти, найбільш імовірно, будуть виникати у відповідь на запит PUT. Якщо використовується версифікація, і об’єкт, який повинен бути поміщений, включає зміни ресурсу, які знаходяться в протиріччі із зробленими раніше небудь запитом (третьої сторони), сервер МОЖЕ використовувати відповідь з кодом стану 409, щоб показати, що він не може виконати запит. В цьому випадку, об’єкту відповіді СЛІД містити список відмінностей двох версій в форматі, визначеному полем заголовка відповіді Content-Type.

10.4.11 410 Вилучений, Gone.


Запитаний ресурс більше недоступний на сервері, і немає ніякого адреси для перенаправлення запиту. Такий стан СЛІД розглядати як постійне. Клієнтам з можливостями редагування гіперзв’язки СЛІД видалити посилання на запитуваний URI (Request-URI) після схвалення користувачем. Якщо сервер не знає, або не може визначити, чи є таке положення постійним чи ні, то йому СЛІД замість цього коду використовувати код стану 404 (Не знайдений, Not Found). Ця відповідь є Кешована, якщо не позначено іншого.
Відповідь з кодом стану 410 призначений насамперед для того, щоб допомогти в супроводі WWW, повідомляючи одержувача, що ресурс навмисно недоступний і що власники сервера бажають, щоб віддалені зв’язку, що вказують на цей ресурс були вилучені. Таке трапляється в основному для обмежених за часом, рекламних сервісів і для ресурсів, що належать особам, більше не займаються сайтом. Не обов’язково відзначати всі постійно недоступні ресурси як “віддалені” (“gone”) або зберігати запис в протягом будь-якого відрізка часу – це надається на розсуд власника сервера.

10.4.12 411 Требуется довжина, Length Required.


Сервер відмовляється приймати запит з невизначеним Content-Length. Клієнт МОЖЕ повторити запит, якщо додасть допустиме поле заголовка Content-Length, що містить довжину тіла повідомлення (message-body) в повідомленні запиту.

10.4.13 412 Передумови невірно, Precondition Failed.


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

10.4.14 413 Об’єкт запиту занадто великий, Request Entity Too Large.


Сервер відмовляється обробляти запит, тому що об’єкт запиту більше, ніж сервер бажає або здатний обробити. Сервер може закрити з’єднання, щоб не дати клієнтові можливість продовжити запит.
Якщо це тимчасовий стан, то серверу СЛІД включити поле заголовка Retry-After для вказівки часу, через який клієнт може знову повторити запит.

10.4.15 414 URI запиту занадто довгий, Request-URI Too Long.


Сервер відмовляється обслуговувати запит, тому що запитуваний URI (Request-URI) довше, ніж сервер бажає інтерпретувати. Це рідкісний стан, яке, ймовірно, відбувається тільки тоді, коли клієнт неправильно перетворив запит POST до запиту GET з довгою інформацією запиту, або коли клієнт потрапив в “Чорну діру” URL перенаправлення (наприклад, перенаправлений URL префікс вказує на свій суфікс), або коли на сервер проводиться напад клієнтом, які намагаються експлуатувати лазівки в секретності, наявні в деяких серверах, використовують буфера фіксованої довжини для читання або маніпулювання із запитуваною URI (Request-URI).

10.4.16 415 Непідтримуваний медіа тип, Unsupported Media Type.


Сервер відмовляється обслуговувати запит, тому що об’єкт запиту знаходиться в форматі, не відповідати вказаній ресурсом для запитаного методу.

10.5 5xx – Коди помилок сервера.


Коди стану, що починаються з цифри “5” вказують випадки, в яких сервер знає, що допустив помилку чи нездатний виконати запит. Відповідаючи на запит, за винятком запиту HEAD, серверу СЛІД включити об’єкт, що містить пояснення помилкової ситуації та інформацію, чи є це положення тимчасовим або постійним. Агентам користувача СЛІД показувати користувачеві будь включений об’єкт. Ці коди стану застосовні до будь-якого методу запиту.

10.5.1 500 Внутрішня помилка сервера, Internal Server Error.


Сервер зіткнувся з непередбаченим умовою, яка не дозволяє йому виконати запит.

10.5.2 501 Чи не реалізовано, Not Implemented.


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

10.5.3 502 Помилка шлюзу, Bad Gateway.


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

10.5.4 503 Сервіс недоступний, Service Unavailable.


Сервер в даний час не здатний обробити запит через тимчасової перевантаження або обслуговування сервера. Це тимчасове умова, яку буде полегшено після деякої затримки. Якщо відома тривалість затримки, вона може бути зазначена в заголовку Retry-After. Якщо Retry-After не присутній в відповіді, клієнтові СЛІД обробляти цю відповідь як відповідь з кодом
500.
Зверніть увагу: існування коду стану 503 НЕ увазі, що сервер повинен використовувати його, коли перевантажений. Деякі сервера можуть просто закривати з’єднання.

10.5.5 504 закінчено час очікування від шлюзу, Gateway Timeout.


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

10.5.6 505 Чи не підтримувана версія HTTP, HTTP Version Not Supported.


Сервер не підтримує, або відмовляється підтримувати, версію HTTP протоколу, яка використовується в повідомленні запиту. Сервер вказує, що не здатний або не бажає виконувати запит, використовуючи ту ж саму major версію, що і клієнт, як описано в розділі 3.1, в інших повідомленнях. Відповіді СЛІД містити об’єкт, описує, чому ця версія не підтримується, і які інші протоколи підтримуються цим сервером.

11 Встановлення автентичності доступу (Access Authentication).


HTTP забезпечує для встановлення автентичності простий механізм виклик-відповідь (challenge-response), який МОЖЕ використовуватися сервером для виклику (challenge) клієнтського запиту, а клієнтом для надання розпізнавального інформації (authentication information). Він використовує розширювану, не чутливу до регістру лексему ідентифікації схеми встановлення автентичності (Authentication scheme) та відокремлений комою список пар атрибут-значення (attribute-value), які представляють параметри, необхідні для встановлення автентичності з використанням цієї схеми.
auth-scheme = token
auth-param = token “=” quoted-string
Повідомлення відповіді з кодом 401 (несанкціоновано, Unauthorized) використовується первісним сервером для виклику (challenge) встановлення автентичності (authorization) агентом користувача. Ця відповідь ПОВИНЕН містити поле заголовка WWW-Authenticate, включає принаймні один виклик (challenge), що застосовується до запрошенням ресурсу.
challenge = auth-scheme 1*SP realm *( “,” auth-param )
realm = “realm” “=” realm-value
realm-value = quoted-string
Атрибут області (realm) (не чутливий до регістру) потрібно для всіх схем встановлення автентичності, які видають виклик (Challenge). Значення атрибута realm (чутливе до регістру), в комбінації з канонічним кореневим URL (дивитися розділ 5.1.2) сервера, до якого звернуто запит, визначає область захисту (Protection space). Ці області дозволяють розбивати захищені ресурси сервера на безліч областей, кожна з яких має власну розпізнавальну схему та / або базу даних встановлення автентичності (authorization database). Значення realm – рядок, взагалі кажучи призначена первісним сервером, яка може мати додаткову семантику, специфічну для схеми встановлення автентичності (authentication scheme).
Агент користувача, який хоче довести свою справжність серверу, зазвичай, але не обов’язково, МОЖЕ це зробити після отримання відповіді з кодом стану 401 або 411, включивши поле заголовка Authorization до запиту. Значення поля Authorization складається з рекомендацій (credentials), що містять інформацію встановлення автентичності (authentication information) агента користувача для області (realm) запитаного ресурсу.
credentials = basic-credentials
| auth-scheme #auth-param
Область (domain), над якою рекомендації (credentials) можуть автоматично застосовуватися агентом користувача, визначена областю захисту (protection space). Якщо справжність була встановлена ​​попереднім запитом, то ці ж рекомендації (Credentials) МОЖУТЬ використовуватися багаторазово у всіх інших запитах всередині цієї галузі захисту (protection space) протягом часу, визначеного схемою встановлення справжності, параметрами, та / або установками користувача. Якщо схемою встановлення автентичності не визначено іншого, то одиночна область захисту (protection space) не може сягати ширше області сервера (the scope of its server).
Якщо сервер не бажає приймати рекомендації (credentials), послані в запиті, то йому слід повернути відповідь з кодом 401 (Несанкціоновано, Unauthorized). Відповідь ПОВИНЕН включати поле заголовка WWW-Authenticate, що містить (можливо новий) виклик (Challenge), що застосовується до запрошенням ресурсу, і об’єкт, пояснювала відмову.
Протокол HTTP не обмежує застосування використанням цього простого механізму виклик-відповідь (challenge-response) для встановлення автентичності доступу. МОЖНА використовувати додаткові механізми, такі як шифрування на транспортному рівні або формування пакета повідомлення (message encapsulation) з додатковими полями заголовка, визначальними інформацію встановлення автентичності. Проте ці додаткові механізми не визначені в цій специфікації.
Проксі-сервера ПОВИННІ бути повністю прозорі для встановлення справжності агента користувача. Тобто вони ПОВИННІ пересилати заголовки WWW-Authenticate і Authorization недоторканими і слідувати правилам розділу 14.8.
HTTP/1.1 дозволяє клієнту передавати інформацію встановлення автентичності і від проксі-сервера за допомогою заголовків Proxy-Authenticate і Proxy-Authorization.

11.1 Базова схема встановлення автентичності (Basic Authentication


Scheme).
“Базова” схема встановлення автентичності заснована на тому, що агент користувача повинен доводити свою справжність за допомогою ідентифікатора користувача (user-ID) і пароля (password) для кожній області (realm). Значенням області (realm) слід бути непрозорою (opaque) рядком, яку можна перевіряти тільки на рівність з іншими областями на цьому сервері. Сервер обслужить запит, тільки якщо він може перевірити правильність ідентифікатора користувача (user-ID) і пароля (password) для захищеної області (Protection space) запитаного URI (Request-URI). Ніяких опціональних розпізнавальних параметрів немає.
Після отримання запиту на URI, що знаходиться в захищається області (Protection space), сервер МОЖЕ відповісти викликом (challenge), подібним наступного:
WWW-Authenticate: Basic realm=”WallyWorld”
де “WallyWorld” – рядок, призначена сервером, яка ідентифікує область захисту запитуваної URI (Request-URI).
Щоб отримати права доступу, клієнт посилає ідентифікатор користувача (userid) і пароль (password), розділені одним символом двокрапки (“:”), всередині base64-кодованої рядка рекомендацій (credentials).
basic-credentials = “Basic” SP basic-cookie
basic-cookie =
user-pass = userid “:” password
userid = *
password = *TEXT
Userid може бути чутливий до регістру.
Якщо агент користувача хоче послати ідентифікатор користувача (Userid) “Aladdin”, і пароль (password) “open sesame”, він буде використовувати наступне поле заголовка:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Угоди про захист, пов’язані з базовою схемою встановлення автентичності, дивіться в розділі 15.

11.2 Оглядова схема встановлення автентичності (Digest Authentication


Scheme).
Оглядовий встановлення автентичності HTTP визначається в
RFC 2069 [32].

12 Обговорення вмісту (Content Negotiation).


Більшість HTTP відповідей включають об’єкт, який містить інформацію, призначену для інтерпретації користувачем. Природно бажання забезпечити користувача “кращим доступним” об’єктом, відповідним запитом. На жаль для серверів і кешей, не всі користувачі мають одіннаковом переваги, і не всі агенти користувача однаково здатні до візуалізації всіх типів об’єктів. З цієї причини, HTTP має кошти для декількох механізмів “обговорення вмісту” – процесу вибору найкращого представлення для даної відповіді, коли доступно кілька подань.
Зверніть увагу: Це не викликається “обговорення формату” (“Format negotiation”), тому що альтернативні уявлення можуть мати одіннаковом медіа тип, але використовувати різні можливості цього типу, мати різні мови і т.д.
Будь-яка відповідь, що містить тіло об’єкта (entity-body) МОЖЕ бути темою обговорення, включаючи помилкові відповіді.
Є два види обговорення вмісту, які можливі в HTTP: кероване сервером і кероване агентом обговорення. Ці два виду обговорення незалежні, і, таким чином, можуть використовуватися окремо або разом. Один метод використання їх разом, згадуваний як прозоре обговорення, відбувається, коли кеш використовує інформацію обговорення, керованого агентом, надаючи її первісного серверу, для забезпечення керованого сервером обговорення при наступних запитах.

12.1 Кероване сервером обговорення.


Обговорення називається керованим сервером, якщо вибір самого кращого уявлення для відповіді зроблений алгоритмом, розміщеним на сервері. Вибір заснований на доступних уявленнях відповіді (вони можуть відрізнятися за кількома характеристиками; наприклад мови, кодування вмісту (content-coding), і т.д.) і змісті специфічних полів заголовка в повідомленні запиту, або на інший інформації, що має відношення до запиту (такий як мережеву адресу клієнта).
Кероване сервером обговорення вигідно, коли алгоритм вибору з числа доступних уявлень важко описати агенту користувача, або коли сервер бажає послати “краще припущення” клієнту одночасно з першою відповіддю (сподіваючись уникнути затримки пересилання туди і назад подальшого запиту, якщо “краще припущення” влаштує користувача). Щоб поліпшити припущення сервера, агент користувача МОЖЕ включати поля заголовка запиту (Accept, Accept-Language, Accept-Encoding, і т.д.), які описують кращий відповідь.
Кероване сервером обговорення має недоліки:
1. Сервер не може точно визначити, що могло б бути “самим кращим “для даного користувача, так як це вимагає повного знання, як можливостей агента користувача, так і цілей використання відповіді (наприклад, користувач хоче переглядати його на екрані або друкувати на папері?).
2. Наявність опису можливостей агента користувача в кожному запиті може бути дуже неефективним (за умови, що тільки невеликий відсоток відповідей має кілька уявлень) і потенційно порушує секретність користувача.
3. Воно ускладнює реалізацію початкового сервера і алгоритмів генерації відповідей на запит.
4. Воно може обмежувати здатність загального кешу використовувати один і той же відповідь на запити декількох користувачів.
HTTP/1.1 включає наступні поля заголовка запиту (Request-header), які забезпечують кероване сервером обговорення за допомогою опису можливостей агента користувача і переваг самого користувача: Accept (розділ 14.1), Accept-Charset (розділ 14.2), Accept-Encoding (розділ 14.3), Accept-Language (розділ 14.4), and User-Agent (розділ 14.42). Проте первинний сервер не обмежений цим і МОЖЕ змінити відповідь, грунтуючись на будь-якому аспекті запиту, включаючи інформацію, яка не міститься в полях заголовка запиту або інформацію з розширених полів заголовка, не визначених у цій специфікації.
Початковий сервер HTTP/1.1 ПОВИНЕН включати відповідне поле заголовка Vary (розділ 14.43) в будь Кешована відповідь, заснований на управлямом сервером обговоренні. Поле заголовка Vary описує характеристики, які можуть змінюватися у відповіді (тобто характеристики, згідно з якими первинний сервер вибирає “Найкращий” відповідь з кількох вистав).
Загальні HTTP/1.1 кеші ПОВИННІ розпізнати поле заголовка Vary, якщо він присутній у відповіді, і відповідати вимогам, описаним в розділі 13.6, який описує взаємодії між кешуванням і обговоренням вмісту.

12.2 Кероване агентом обговорення.


При керованому агентом обговоренні, вибір кращого подання відповіді виконується агентом користувача після отримання початкового відповіді початкового сервера. Вибір заснований на списку доступних уявлень відповіді, включеному в поля заголовка (ця специфікація резервує ім’я поля Alternates, як описано в додатку 19.6.2.1) або тіло об’єкта початкового відповіді. Кожне подання ідентифікується власним URI. Вибір подання може виконуватися автоматично (якщо агент користувача здатний це зробити) або вручну користувачем з згенерованого (можливо гіпертекстового) меню.
Кероване агентом обговорення вигідно, коли відповідь варіюється по общеіспользуемой характеристикам (таким як тип, мова, або кодування), коли первісний сервер не здатний визначити можливості агента користувача шляхом дослідження запиту, і зазвичай при використанні загальних кешей для розподілу навантаження на сервер і зменшення використання мережі.
Кероване агентом обговорення страждає тим, що для отримання найкращого альтернативного подання потрібно другий запит. Цей другий запит ефективний тільки тоді, коли використовується кешування. Крім того, ця специфікація не визначає ніякого механізму для забезпечення автоматичного вибору, хоча також і не запобігає розробку такого механізму як розширення і використання в HTTP/1.1.
HTTP/1.1 визначає коди стану 300 (Множинний вибір, Multiple Choices) і 406 (Не прийнятний, Not Acceptable) для забезпечення керованого агентом обговорення, коли сервер не бажає або не здатний забезпечити зміну відповіді, використовуючи кероване сервером обговорення.

12.3 Прозоре обговорення.


Прозоре обговорення – це комбінація керованого сервером і керованого агентом обговорення. Коли кеш забезпечений списком доступних уявлень відповіді (як при керованому агентом обговоренні) і змінюються характеристики повністю зрозумілі кешем, тоді він здатний виконувати кероване сервером обговорення подальших запитів цього ж ресурсу від імені початкового сервера.
Прозоре обговорення має ту перевагу, що робота по обговорення розподіляється. Коли кеш здатний правильно припустити потрібну відповідь скорочується робота, яка раніше потрібна від початкового сервера і не відбувається затримки другого запиту, як при керованому агентом обговоренні.
Ця специфікація не визначає жодного механізму прозорого обговорення, хоча також і не запобігає розробку такого механізму як розширення і використання в HTTP/1.1. HTTP/1.1 кеш, що виконує прозоре обговорення ПОВИНЕН включати поле заголовка Vary (визначальне параметри, які можуть змінюватись) у відповідь, якщо він кешіруем, щоб гарантувати правильну інтерпретацію всіма HTTP/1.1 клієнтами. Інформацію керованого агентом обговорення, представлену початковим сервером, СЛІД включати у відповідь при прозорому обговоренні.

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


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

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

Ваш отзыв

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

*

*