Протокол HTTP 1.1

Комунікації і зв'язок

Московський державний інститут радіотехніки, електроніки і АВТОМАТИКИ
(Технічний університет)

Заліковий РОБОТА

ПЗ

ДИСЦИПЛІНИ

«Інформаційно-обчислювальні мережі»

НА ТЕМУ

«Протокол HTTP 1.1»

МОСКВА 2002
Зміст
1. Введення. 5
1.1. Призначення 5
1.3 Термінологія. 5
2. Загальний опис. 8
3. Установки протоколу. 11
3.1 Версія HTTP. 11
3.2 Універсальний Ідентифікатор Ресурсу (URI). 12

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

3.2.2 HTTP URL. 13

3.2.3 Порівняння URI. 13
3.3 Формати дати і часу. 14

3.3.1 Повна дата. 14

3.3.2 Різниця секунд (delta seconds). 15
3.4 Кодові таблиці (character sets). 15
3.5 Кодування вмісту (content codings). 15
3.6 Кодування передачі (Transfer Codings). 16
3.7 Медіатіпи (Media Types). 17

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

3.7.2 Типи Multipart. 19
3.8 Маркери продуктів (Product Tokens). 19
3.9 Величини якості (Quality Values). 20
3.10 Мітки мов (Language Tags). 20
3.11 Мітки об'єктів (Entity Tags). 21
3.12 Одиниці виміру діапазонів (Range Units). 21
4. HTTP повідомлення (HTTP Message). 22
4.1 Типи повідомлень. 22
4.2 Заголовки повідомлень. 22
4.3 Тіло Cообщения. 23
4.4 Довжина повідомлення. 24
4.5 Загальні поля заголовка. 25
5. Запит (Request). 25
5.1 Рядок запиту (Request-Line). 25

5.1.1 Метод (Method). 25

5.1.2 URI запиту (Request-URI). 26

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

5.3 Поля заголовка запиту. 28
6 Відповідь (Response). 28
6.1 Рядок стану (Status-Line). 28

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

6.2 Поля заголовка відповіді. 30
7 Об'єкт (Entity). 30
7.1 Поля заголовка об'єкта. 30
7.2 Тіло об'єкта. 31

7.2.1 Тип. 31

7.2.2 Довжина. 32
8 З'єднання (Connections). 32
8.1 Постійні з'єднання (Persistent Connections). 32

8.1.1 Мета. 32

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

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

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

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

8.1.4 Практичні міркування. 34

8.2 Вимоги до передачі повідомлень. 34
9 Визначення методів. 36
9.1 Безпечні і Ідемпотентний методи. 36

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

9.1.2 Ідемпотентний методи. 37
9.2 OPTIONS. 37
9.3 GET. 38
9.4 HEAD. 38
9.5 POST. 38
9.6 PUT. 39
9.7 DELETE. 40
9.8 TRACE. 41
10 Визначення кодів стану. 41
10.1 1xx - Інформаційні коди. 41
10.1.1 100 Продовжувати, Continue. 41
10.1.2 101 Перемикання протоколів, Switching Protocols 42
10.2 2xx - Успішні коди. 42

10.2.1 200 OK. 42

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

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

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

10.2.5 204 Ні вмісту, No Content. 43

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

10.2.7 206 Часткове вміст, Partial Content. 44
10.3 3xx - Перенаправлення. 44

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

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

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

10.3.4 303 фото інший, See Other. 45

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

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

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

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

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

10.4.3 402 Потрібен оплата, Payment Required. 47

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

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

10.4.6 405 Метод не допустимо, Method Not Allowed. 48

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

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

Authentication Required. 48

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

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

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

10.4.12 411 Потрібно довжина, Length Required. 50

10.4.13 412 передумова невірно, Precondition Failed. 50

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

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

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

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

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

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

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

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

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

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

52
11 Встановлення автентичності доступу (Access Authentication). 52
11.1 Базова схема встановлення автентичності (Basic Authentication Scheme).
53
11.2 Оглядова схема встановлення автентичності (Digest Authentication
Scheme) [1]. 54
13 Кешування в HTTP. 54
13.1 Загальна інформація про кешуванні. 55

13.1.1 Правильність кеша. 55

13.1.2 Попередження. 56

13.1.3 Механізми управління кешем (Cache-control Mechanisms). 57

13.1.4 Явні попередження агента користувача. 57

13.1.5 Винятки з правил і попереджень. 57

13.1.6 Контрольоване клієнтом поведінку. 58
13.2 Модель старіння. 58

13.2.1 Старіння, вказане сервером. 58

13.2.2 Евристичне старіння. 59

13.2.3 Обчислення віку. 59

13.2.4 Обчислення старіння. 61

13.2.5 Усунення суперечностей у значеннях старіння. 62

13.2.6 Усунення суперечностей між кількома відповідями. 62
13.3 Модель перевірки достовірності (validation model). 63
Бібліографічний список 65

1. Введення.

Протокол передачі гіпертексту (HTTP) - протокол прикладного рівня длярозподілених, спільних, многосредних інформаційних систем. HTTPвикористовується в World Wide Web (WWW) починаючи з 1990 року. Першою версією
HTTP, відомої як HTTP/0.9, був простий протокол для передачінеоброблених даних через Інтернет. За визначенням RFC 1945 HTTP/1.0 бувполіпшенням цього протоколу, допускав MIME-подібний формат повідомлень,що містить метаінформації про переданих даних і мав модифікованусемантику запитів/відповідей. Однак HTTP/1.0 недостатньо враховувавособливості роботи з ієрархічними проксі-серверами (hierarchicalproxies), кешуванням, постійними сполуками, і віртуальними хостами
(virtual hosts). Крім того, швидке зростання числа не повністю сумісних зпротоколом HTTP/1.0 додатків, зажадав введення нової версії протоколу,в якій було б закладено додаткові можливості, які допомогли бпривести ці додатки до єдиного стандарту.

Список RFC що відноситься до розглянутих в даній роботі питань,наведений у розділі «Бібліографічний список».

1.1. Призначення

Протокол HTTP/1.1 містить більш суворі вимоги, ніж HTTP/1.0,гарантують більш надійну роботу.

Великі інформаційні системи вимагають більшої кількостіфункціональних можливостей, ніж просто завантаження інформації, включаючи пошукі модифікацію даних за допомогою зовнішніх інтерфейсів. HTTP надаєвідкритий (open-ended) набір методів, які засновані на системі посилань,які забезпечуються URI (універсальний ідентифікатор Ресурсів). URIможуть ідентифікувати як розташування (URL), так і ім'я (URN) ресурсу, доякого застосовується даний метод. Повідомлення передаються в форматі,подібного використовуваному електронною поштою згідно визначень MIME
(Багатоцільових розширення електронної пошти).

HTTP також використовується як узагальнений протокол зв'язку між агентамикористувачів (user agents) і проксі-серверамі/шлюзамі (proxies/gateways)або іншими Інтернет-сервісами, включаючи такі як SMTP, NNTP, FTP, Gopher і
WAIS. Таким чином, HTTP визначає основи многосредного доступу доресурсів для різноманітних додатків.

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

- З'єднання (connection).

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

- Повідомлення (message).

Основний модуль HTTP зв'язку, що складається з структурної послідовності октетів, відповідних синтаксису протоколу і та з'єднанням.

- Запит (request)

Будь-яке HTTP повідомлення, що містить запит.

- Відповідь (response).

Будь-яке HTTP повідомлення, що містить відповідь.

- Ресурс ( resource).

Мережний об'єкт даних або сервіс, який може бути ідентифікований

URI. Ресурси можуть бути доступні в кількох виставах (наприклад на декількох мовах, в різних форматах даних, мати різний розмір або різну роздільну здатність) або різнитися за іншими параметрами.

- Об'єкт (entity). < p> Інформація, передана в якості корисного навантаження запиту або відповіді. Об'єкт складається з метаінформації у формі полів заголовка об'єкта і змісту у формі тіла об'єкта.

- Подання (representation).

Об'єкт включений у відповідь, і підзвітний обговорення вмісту < p> (Content Negotiation). Може існувати кілька подань, пов'язаних зі специфічними станами відповіді.

- Обговорення вмісту (content negotiation).

Механізм для вибору відповідного подання під час обслуговування запиту. Подання об'єктів в будь-якій відповіді може бути обговорено (включаючи помилкові відповіді).

- Варіант (variant).

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

Використання терміну "варіант" не обов'язково має на увазі, що ресурс підпорядкований обговорення вмісту.

- Клієнт (client)

Програма, яка встановлює з'єднання з метою посилки запитів.

- Агент користувача (user agent).

Клієнт, який ініціює запит. Як правило браузери, редактори, роботи (spiders), або інші інструментальні засоби користувача.

- Сервер (server).

Додаток, який слухає з'єднання, приймає запити на обслуговування та надсилає відповіді . Будь-яка така програма здатна бути як клієнтом, так і сервером; наше використання даного терміну відноситься швидше до ролі, яку програма виконує, створюючи специфічні сполуки, ніж до можливостей програми взагалі.

Аналогічно, будь-який сервер може діяти як початковий сервер

(origin server), проксі-сервер (proxy), шлюз (gateway) або тунель

(tunnel), змінюючи поведінку, грунтуючись на характері кожного запиту.

- Первинний сервер (origin server).

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

- Проксі-сервер (proxy).

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

- Шлюз (gateway).

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

- Тунель (tunnel).

Програма-посередник, яка підтримує з'єднання. Один раз створений, тунель не розглядається як частина HTTP зв'язку, хоча тунель, можливо, був ініціалізований запитом HTTP. Тунель припиняє існувати, коли обидва кінці з'єднання закриваються.

- Кеш (cache).

Локальна пам'ять, в якій програма зберігає повідомлення-відповіді, і в якій розташовується підсистема, що управляє зберіганням, пошуком і видаленням повідомлень. Кеш зберігає відповіді, які можуть бути збережені, щоб зменшити час відповіді і завантаження мережі (трафік) при майбутніх еквівалентних запитах. Будь-який клієнт або сервер може мати кеш, але кеш не може використовуватися сервером, який діє як тунель.

- Кешована (cachable).

Відповідь є Кешована, якщо кешу дозволено зберегти копію відповідного повідомлення для використання при відповіді на наступні запити. Навіть якщо ресурс кешіруем, можуть існувати додаткові обмеження на використання кешем збереженої копії для вихідного запиту.

- Безпосередній (first-hand).

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

- Точний час старіння (explicit expiration time).

Час певний первинним сервером і показує кешу коли об'єкт більше не може бути повернений клієнтові без додаткової перевірки достовірності.

- Евристичне час старіння (heuristic expiration time).

Час старіння, призначене кешем, якщо не вказано точний час старіння.

- Вік (age).

Вік відповіді - час, що минув з моменту відсилання, або успішної перевірки відповіді первинним сервером.

- Час життя (freshness lifetime).

Відрізок часу між породженням відповіді і моментом старіння.

- Свiжий (fresh).

Відповідь вважається свіжим, якщо його вік ще не перевищив час життя.

- Просроченнний (stale).

Відповідь вважається простроченим, якщо його вік перевищив час життя.

- Семантично прозорий (semantically transparent).

Кажуть, що кеш поводиться "семантично прозорим" чином відносно специфічного відповіді, коли використання кешу не впливає ні на клієнта запиту, ні на початковий сервер, але підвищує ефективність. Коли кеш семантично прозорий, клієнт отримує точно таку ж відповідь (за винятком проміжних (hop-by-hop) заголовків), який отримав би, запитуючи безпосередньо первинний сервер, а не кеш.

- Покажчик достовірності (validator ).

Елемент протоколу (наприклад, мітка об'єкта або час останньої модифікації (Last-Modified time)), який використовується, щоб з'ясувати, чи є що знаходиться в кеші копія еквівалентом об'єкта.

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

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

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

Більш складна ситуація виникає, коли в ланцюжку запитів/відповідейприсутній один або декілька посередників. Існують три основнірізновиди посередників: проксі-сервера, шлюзи, і тунелі. Проксі-серверє агентом-посередником, який отримує запити на деякий URI вабсолютній формі, змінює всі повідомлення або його частина і відсилаєзмінений запит серверу, ідентифікованого URI. Шлюз - це приймаєагент, що діє як би на рівень вище деякого іншого сервера (ів) іпри необхідності транслює запити до протоколу основного сервера.
Тунель діє як реле (relay) між двома з'єднаннями не змінюючиповідомлень; тунелі використовуються, коли зв'язок потрібно робити черезпосередника (наприклад firewall), яка не розуміє зміст повідомлень.

На малюнку показані три посередника (A, B і C) між агентомкористувача і первісним сервером. Запити та відповіді передаються черезчотири окремі з'єднання. Ця відмінність важливо, тому що деякі опції
HTTP з'єднання застосовні тільки до з'єднання з найближчим НЕ тунельнимсусідом, деякі тільки до кінцевих точках ланцюжки, а деякі до всіхз'єднанням в ланцюжку. Хоча ця діаграма лінійна, кожен учасник можебути задіяний у кількох з'єднаннях одночасно. Наприклад, B можеотримувати запити від інших клієнтів, а не тільки від A, і/або пересилатизапити серверів, відмінним від C, в той же час, коли він обробляєзапит А.

Будь-яка сторона з'єднання, яка діє не як тунель, можевикористовувати внутрішній кеш для обробки запитів. Ефект кешу полягаєв тому, що ланцюжок запитів/відповідей скорочується, якщо один з учасників уланцюжку має кешовані відповідь, що задовольняє даному запиту. Даліпоказана ланцюжок, що виникає в тому випадку, коли B має кешування копіюраннього відповіді O (отриманий через C) на запит, і який не бувкешовані ні UA, ні A.

Не всі відповіді корисно кешувати, а деякі запити можуть міститимодифікатори, які вказують спеціальні вимоги, що керуютьповедінкою кеша.

Фактично, є широке розмаїття архітектур і конфігураційкешей і проксі-серверів, що розробляються в даний час або розгорнутихв World Wide Web; ці системи включають національні ієрархії проксі-кешей,які зберігають пропускну здатність міжокеанського каналів, системи,які поширюють за багатьма адресами вміст кеша, організації,які поширюють підмножини Кешована даних на CD-ROM, і такдалі. HTTP системи використовуються в корпоративних інтранет-мережах звисокошвидкісними лініями зв'язку, і для доступу через PDA з малопотужнимирадіолінії і нестійкою зв'язком. Мета HTTP/1.1 полягає в підтримціширокого різноманіття конфігурацій, вже побудованих при введенні ранніхверсій протоколу, а також у задоволенні потреб розробників webдодатків, що вимагаютьвсе більш високій надійності.

HTTP підключення зазвичай відбувається за допомогою TCP/IP з'єднань.
Вказаний за замовчуванням порт TCP - 80, але можуть використовуватися і інші порти
(наприклад: 8080, 8081). HTTP також може бути реалізований за допомогою будь-якогоіншого протоколу Інтернет, або інших мереж. HTTP необхідна тількинадійна передача даних, відтак може використовуватися будь-якийпротокол, який гарантує надійну передачу даних; відображенняструктури запиту і відповіді HTTP/1.1 на транспортні модулі данихрозглянутого протоколу - питання, не вирішується на рівні самогопротоколу.

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

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/1.1, повинні вказувати версію 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) абощодо деякого відомого основного URI (relative URI), уЗалежно від контексту їх використання. Ці дві форми розрізняються тим,що абсолютні 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)

escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" |

"=" | "+" extra = "!" | "*" | " '" | "(" | ")" | "," Safe = "$" | "-" |

"_" | "." unsafe = CTL | SP | | "#" | "%" | "" national =

Повна інформація про синтаксис і семантику URL міститься в RFC 1738 і
RFC 1808. Нормальна запис Бекуса-Наура включає національні символи,недозволені в правильних URL, визначених RFC 1738, так як HTTP серверидозволяють використовувати для представлення частини rel_path адрес набір незарезервованих символів, і, отже, HTTP проксі-сервера можутьодержувати запити URI, що не задовольняють RFC 1738.

Протокол HTTP не накладає жодних обмежень на довжини URI. Сервериповинні обробляти URI будь-якого ресурсу, будь-якої довжини, який вониобслуговують, і їм слід обробляти URI необмеженої довжини, якщо вониобслуговують сервера, засновані на методі GET, які можуть створюватитакий URI. Серверу слід повертати код стану 414 (URI запитузанадто довгий, Request-URI Too Long), якщо URI довше, ніж сервер встані обробити.

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

3.2.2 HTTP URL.

"Http" схема використовується для доступу до мережевих ресурсів за допомогоюпротоколу HTTP. Цей розділ визначає схемо-певний синтаксис ісемантику для HTTP URL.

http_URL = "http:" "/ /" host [ ":" port] [abs_path]

host =

port = * DIGIT

Якщо порт порожній або не заданий - використовується порт 80. Це означає, щоідентифікований ресурс розміщений в сервер, що очікують TCP з'єднань наспецифіковані порте port, комп'ютера host, і запитаний URI ресурсу
- Abs_path. Використання IP адрес в URL слід уникати, наскільки цеможливо (RFC 1900). Якщо abs_path не представлений в URL, він повиненрозглядатися як "/" при обчисленні запитуваного URI (Request-URI)ресурсу.

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

При порівнянні двох URI, щоб вирішити чи відповідають вони один одномучи ні, клієнт має використовувати чутливе до регістру пооктетное
(octet-by-octet) порівняння цих URI, з наступними виключеннями:

- Порт, який порожній або не вказаний, еквівалентний заданого за замовчуванням порту для цього URI;

- Порівняння імен хостів повинно проводитися без урахування регістру;

- Порівняння імен схем повинно проводитися без урахування регістру;

- Порожній abs_path еквівалентний "/".

- Символи, відмінні від тих, що знаходяться в "зарезервованих"

( "reserved") і "небезпечних" ( "unsafe") наборах еквівалентні їх поданням як ""% "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 08:49:37 GMT; RFC 822, доповнений на; RFC 1123

Sunday, 06-Nov-94 08:49: 37 GMT; RFC 850, переписаний як; RFC 1036

Sun Nov 6 08:49:37 1994; формат asctime () ANSI C

Перший формат вибраний як стандарт Інтернету і представляєпідмножина фіксованої довжини, як визначено в RFC 1123
(модифікованому RFC 822). Другий формат перебуває в загальному користуванні, алезаснований на застарілому і втратив статус стандарту RFC 850, що описуєформати дат, він володіє тим недоліком, що рік вказується не вчотирирозрядний нотації. Клієнти і сервери 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

time = 2DIGIT ": "2DIGIT": "2DIGIT; 00:00:00 - 23:59:59

wkday =" Mon "|" Tue "|" Wed "|" Thu "|" Fri "|" Sat " | "Sun"

"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:

Термін "кодова таблиця" використовується, щоб послатися на метод,що використовує одну або декілька таблиць для перетворенняпослідовності октетів в послідовність символів. Варто відзначити,що однозначне перетворення у зворотному напрямку не потрібна, і щоне всі символи можуть бути доступні в цiй кодової таблиці, і що кодоватаблиця може забезпечувати більш ніж одну послідовність октетів дляпредставлення специфічних символів. Це визначення допускає різнівиди кодування символів, від простих однотаблічних відображень типу US-
ASCII до складних методів, перемикаючих таблиці, на зразок тих, яківикористовують методики ISO 2022. Однак визначення, пов'язане з ім'ямкодової таблиці 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 і Content-Encoding. Хоча значенняописує кодування вмісту, але, що більш важливо - вона вказує,який механізм декодування потрібно для зворотного процесу.

Internet Assigned Numbers Authority (IANA) діє як реєстр длязначень лексем кодування вмісту (content-coding). Спочаткуреєстр містив такі лексеми: gzip Формат кодування, що виробляє стиснення файлу програмою "gzip"

(GNU zip), описаний в RFC 1952. Це формат Lempel-Ziv кодування

(LZ77) з 32 розрядним CRC. compress Формат кодування, вироблений спільною програмою "compress" для стиснення UNIX файлів. Це формат адаптивного Lempel-Ziv-Welch кодування (LZW).

Звичайно, використовувати назви програм для ідентифікації форматівкодування не бажано і може перетинатися з форматами, яківиникнуть надалі. Їх використання пояснюється історичноюпрактикою. Для сумісності з попередніми реалізаціями HTTP, додаткиповинні розглядати "x-gzip" і "x-compress" як еквіваленти "gzip" і
"compress" відповідно. deflate Формат zlib, визначений в 1950, в комбінації з механізмом стиснення "deflate", описаним у RFC 1951.

Нова лексема значення кодування вмісту (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.

Кодування передачі - це аналоги значень Content-Transfer-Encoding
MIME, які були розроблені для забезпечення безпечної передачі двійковихданих при використанні 7-бітового обслуговування передачі. Однак безпечнийтранспорт має інше призначення для чисто 8-бітного протоколупередачі. У HTTP єдина небезпечна характеристика тіла повідомлення викликанаскладністю визначення точної довжини тіла повідомлення, або бажанням шифруватидані при користуванні загальнодоступним транспортом.

Кодування по шматках (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 дляцифрових підписів та інших можливостей.

Всі HTTP/1.1 додатки повинні бути в стані отримувати ідекодувати кодування передачі "по шматках" ( "chunked" transfer coding),і повинні ігнорувати розширення кодування передачі, які вони нерозуміють. Серверу, який отримав тіло об'єкта зі значенням кодуванняпередачі, який він не розуміє, слід повернути відповідь з кодом 501 (Нереалізовано, Not Implemented) і розірвати з'єднання. Сервер не повиненпосилати поля кодування передачі (transfer-coding) HTTP/1.0 клієнтам.

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

HTTP використовує МедіаТіпи Інтернету (Internet Media Types) в поляхзаголовка Content-Type і Accept для забезпечення відкритої і розширюваноїтипізації даних і типів.

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. Використанняне зареєстрованих медіатіпов заборонено.

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" використовується з деякими медіатіпамі для вказівкикодової таблиці, яка використовується для представлення даних. Якщо параметр
"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" - формують пакет зодного або декількох об'єктів всередині тіла одного повідомлення. Усі типиmulptipa