Протокол HTTP 1.1

МОСКОВСКИЙ ДЕРЖАВНИЙ ІНСТИТУТ РАДІОТЕХНІКИ, ЕЛЕКТРОНІКИ І АВТОМАТИКИ (ТЕХНІЧНИЙ УНИВЕРСИТЕТ).

ЗАЛІКОВА РАБОТА.

ПО.

ДИСЦИПЛИНЕ.

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

НА ТЕМУ.

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

|Работу виконав: |Студент 5-го курсу | | |факультету Кібернетики | | |групи ИО-1−97 Фроловичев| | |Сергій | |Викладач: |Дешко І.П. |.

МОСКВА 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) починаючи з року. Першої версією HTTP, відомої як HTTP/0.9, був простий протокол передачі необроблених даних через Інтернет. За визначенням RFC 1945 HTTP/1.0 був поліпшенням цього протоколу, допускав MIME-подобный формат повідомлень, у якому метаінформацію про переданих даних, і мав модифіковану семантику запросов/ответов. Проте HTTP/1.0 недостатньо враховував особливості роботи з ієрархічними прокси-серверами (hierarchical proxies), кэшированием, постійними сполуками, і віртуальними хостами (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).

Інформація, передана як корисною навантаження запиту чи відповіді. Об'єкт складається з метаинформации у вигляді полів заголовка об'єкту і вмісту у формі тіла объекта.

— Уявлення (representation).

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

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

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

— Свіжий (fresh).

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

— Просроченнный (stale).

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

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

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

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

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

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

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

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

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

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

Будь-яка сторона сполуки, яка діє як тунель, може використовувати внутрішній кеш в обробці запитів. Ефект кешу полягає у цьому, що ланцюжок запросов/ответов скорочується, якщо з учасників в ланцюжку має кэшированный відповідь, зрозумілу даному запиту. Далі показано ланцюжок, що виникає у разі, коли B має кэшированую копію раннього відповіді O (полеченного через З) на запит, і який був кэширован ні 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 (HTTPversion) «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).

pchar = uchar | «: «| «@ «| «& «| «= «| «+ «uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national.

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 еквівалентні: internet internet h ttp://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.

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:

Термін «кодова таблиця «використовується, щоб послатися на метод, використовує одну чи кілька таблиць для перетворення послідовності октетів в послідовність символів. Слід зазначити, що однозначне перетворення на напрямку непотрібен, І що в повному обсязі символи може бути доступні у цій кодовою таблиці, І що кодова таблиця може забезпечувати більш як одну послідовність октетів для уявлення специфічних символів. Цю ухвалу допускає різні види кодування символів, від простих однотабличных відбиття типу USASCII до складних методів, переключающих таблиці, на кшталт тих, які використовують методики ISO 2022. Проте визначення, пов’язане з ім'ям кодовою таблиці MIME мав би повністю визначати відображення, яке перетворює октети в символи. Зокрема використання зовнішньої інформації профілювання визначення точного відображення не разрешается.

Кодові таблиці HTTP ідентифікуються лексемами, не чутливими до регістру. Повний набір лексем визначено реєстром кодових таблиць IANA [19].

charset = token.

Хоча HTTP дозволяє вживати як значення charset довільну лексему, будь-яка лексема, має визначене значення в реєстрі кодових таблиць IANA, повинна представляти набір символів, певний у цьому реєстрі. Додатків слід обмежити використання символьних наборів тими, визначених в реєстрі IANA.

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

Значення кодування вмісту вказує яке перетворення кодування було або вона буде застосована об'єкта. Кодування вмісту використовується передусім на стискування чи іншого корисного перетворення документа без втрати ідентифікації основного медиатипа та інформації. Часто, об'єкт зберігається у кодованої формі, потім передається, і потім декодируется получателем.

content-coding = token.

Усі значення кодування вмісту (content-coding) не чутливі до регістру. HTTP/1.1 використовує значення кодування вмісту (contentcoding) в полях заголовка 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).

Значення кодування передачі йдуть на вказівки перетворення кодування, яке було або має бути застосована до тіла об'єкта (entitybody) з метою гарантування «безпечної передачі «через мережу. Воно відрізняється від кодування вмісту тим, що кодування передачі - це властивість повідомлення, а чи не початкового объекта.

transfer-coding = «chunked «| transfer-extension.

transfer-extension = token.

Усі значення кодування передачі (transfer-coding) не чутливі до регістру. HTTP/1.1 використовує значення кодування передачі (transfercoding) на полі заголовка 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 і десяти для 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 з поля contenttype, якщо вони підтримують такий charset, та був використовувати власні установки.

3.7.2 Типи Multipart.

MIME передбачає ряд типів «multipart «- формують пакет з однієї чи кількох об'єктів всередині тіла одного повідомлення. Усі типи mulptipart використовують загальний синтаксис, определеный в MIME, і дружина мають утримувати розділовий параметр частиною значення медиатипа. Тіло повідомлення — самостійний елемент протоколу, й, отже, має використовувати лише СRLF до подання кінців рядків між частинами тіла (body-parts). На відміну від MIME, висновок (epilogue) будь-якого multipart повідомлення має бути порожнім; HTTP докладання нічого не винні передавати висновок (навіть якщо початковий multipart містить заключение).

У HTTP частини тіла (body-parts) типу multipart можуть утримувати поля заголовка, що є значущими в примнении до цієї маленької частини. Поле заголовка Content-Location слід залучити у видаткову частину тіла (body-part) кожного включеного об'єкта, що може бути ідентифікований URL.

Власне кажучи, HTTP агенту користувача належить діяти як і як зробив би MIME агент користувача після отримання типу multipart. Якщо додаток отримує незареєстрований підтип multipart, він повинен обробляти його як підтип «multipart/mixed » .

Тип «multipart/form-data «був спеціально визначено передачі даних форми, підхожих в обробці методом запиту POST, що описано в RFC 1867.

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 використовує короткі числа «з плаваючою точкою «для вказівки відносної важливості («ваги ») різних обумовлених параметрів. Вага — це нормализованое речовинне число буде в діапазоні від 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. Тобто, мітка мови складається з одній або кількох частин: мітка первинного мови та, можливо порожній, ряд підлеглих меток:

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, If-Match, If-None-Match, і If-Range. Мітка об'єкта складається з непрозорою рядки, закладеною у лапки (opaque quoted string), можливо предваренной індикатором слабкості (weakness indicator).

entity-tag = [ weak ] opaque-tag.

weak = «W/ «opaque-tag = quoted-string.

" Сильна мітка об'єкта «(«strong entity tag ») то, можливо распространнена на два об'єкта ресурсу, тільки тоді ми, що вони пооктетно эквивалентны.

" Слабка мітка об'єкта «(«weak entity tag »), обозначяемая префіксом «W/ «, то, можливо поширена два об'єкта ресурсу тільки тоді ми, коли об'єкти еквівалентні і міг би заміняти одне одного без значного зміни у семантикою. Слабка мітка об'єкта може використовуватися лише для слабкого порівняння (weak comparison).

Мітка об'єкта мусить бути унікальна серед усіх версій на всі об'єкти, пов’язаних із конкретним ресурсом. Дане значення мітки об'єкта може використовуватися для об'єктів, отриманих запитами різних URI без припущення еквівалентності цих объектов.

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

HTTP/1.1 дозволяє клієнту вимагати тільки п’яту частину об'єкта. HTTP/1.1 використовує еденицы виміру діапазонів в полях заголовка Range і ContentRange. Об'єкт то, можливо розбитий на частини відповідно різним структурним модулям.

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.

Повідомлення запиту навіть використовують узагальнений формат повідомлення RFC 822 для пересилки об'єктів (корисною навантаження повідомлення). Обидва типу повідомлень виглядають так: спочатку йде початкова рядок (startline), потім чи кілька полів заголовка (званих також просто «заголовки »), потім порожня рядок (тобто, рівна 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, куди входять поля загальних заголовків (generalheader), заголовків запиту (request-header), заголовків відповіді (responseheader), і заголовків об'єкта (entity-header), мають такої ж узагальнений формат, як і той, що описаний розділ 3.1 RFC 822. Кожне полі заголовка складається з імені поля, двокрапки («: ») і значення поля. Імена полів не чутливі до регістру. Значенням поля може передувати будь-яке число LWS, хоча бажаний одиночний SP. Поля заголовка можуть тривати кілька рядків. У цьому кожна така рядок продовження починається по крайнього заходу одним SP чи HT. Додатків слід дотримуватися «загальної форми «(«common form ») при генерації HTTP конструкцій, оскільки можуть існувати реалізації, які може приймати щось крім загальних форм.

message-header = field-name ": «[ field-value ] CRLF.

field-name = token field-value = *(field-content | LWS).

field-content =.

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

Кілька полів заголовка з одиннаковыми іменами можуть бути присутні у міжнародному сполученні тоді й тільки тоді, коли всі значення полів, які входять у заголовок, визначають розділений комами список [тобто #(value)]. Мабуть можливо об'єднати кілька таких полів заголовка до однієї пару «ім'я поля: значення поля «(не измененяя цим семантику повідомлення) шляхом приєднання кожного наступного значення поля до першого через коми. Порядок, у якому отримані половіючі жита із однаковими іменами, має значення для інтерпретації об'єднаного значення поля, і, отже, прокси-сервер ні змінювати порядок значень цього поля при пересылке.

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

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

message-body = entity-body |.

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

Правила, встановлюють допустимість тіла сполучення повідомленні, різняться для запитів і ответов.

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

Вмикати або включати тіло повідомлення (message-body) в повідомлення відповіді залежить як від методу запиту, і від коду стану відповіді. Усі відповіді запит з методом HEAD нічого не винні включати тіло повідомлення (messagebody), навіть якщо присутні поля заголовка об'єкта (entity-header), змушують повірити у присутність об'єкта. Ніякі відповіді з інформаційними кодами стану 1xx, кодом 204 (Ні вмісту, No Content) і кодом 304 (Не модифікований, Not Modified) нічого не винні утримувати тіла повідомлення (message-body). Решта відповіді містять тіло повідомлення, навіть якщо воно має нульову длину.

4.4 Довжина сообщения.

Коли тіло повідомлення (message-body) є у повідомленні, довжина цього тіла визначається однією з наступних методів (гаразд старшинства):

1. Будь-яке повідомлення відповіді, який мав би включати тіло сообщения.

(message-body) (наприклад відповіді з кодами стану 1xx, 204, 304 і всі відповіді запит HEAD) завжди завершується порожній рядком після полів заголовка, незалежно від полів заголовка об'єкта (entityheader fields), які у сообщении.

2. Якщо полі заголовка Transfer-Encoding є і свідчить про застосування кодування передачі «chunked », то довжина визначається кодуванням шматками (chunked encoding).

3. Якщо полі заголовка Content-Length присутній, його значення представляє довжину тіла повідомлення (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 », в такий спосіб дозволяється використання даного механізму для таких повідомлень, довжина яких немає може визначатися заранее.

Повідомлення нічого не винні одночасно включатиме й полі заголовка ContentLength і застосовувати кодування передачі типу «chunked ». Якщо надійшло повідомлення з полем Content-Length і закодоване із застосуванням кодування передачі «chunked », то полі Content-Length має игнорироваться.

Якщо полі Content-Length є у повідомленні, яке допускає наявність тіла повідомлення (message-body), ті значення поля має точно відповідати числу октетів у тілі повідомлення. HTTP/1.1 агенти користувача повинні інформувати користувача у разі здобуття і виявлення неприпустимій длины.

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

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

general-header = Cache-Control | Connection | Date | Pragma | Transfer;

Encoding | Upgrade | Via.

Імена загальних полів заголовка (general-header fields) може бути надійно розширено лише у поєднані із зміною версії протоколу. Проте, нові чи експериментальні поля заголовка можуть одержати семантику загальних полів заголовка (general-header fields), коли всі боку сполуки розпізнають їх як загальні поля заголовка. Нерозпізнані поля заголовка обробляються як поля заголовка об'єкта (entity-header).

5. Запит (Request).

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

Request = Request-Line *(general-header | request-header | entityheader) CRLF [ message-body ].

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 «| «GET «| «HEAD «| «POST «| «PUT «| «DELETE «|.

" TRACE «| extension-method.

extension-method = token.

Список методів, застосовних до ресурсу, то, можливо зазначений на полі заголовка Allow. Возврашаемый код стану відповіді завжди повідомляє клієнту, скажімо чи метод для ресурсу нині, оскільки набір допустимих методів може змінюватися динамічно. Серверам слід повернути код стану 405 (Метод не скажімо, Method Not Allowed), якщо метод відомий серверу, але з застосуємо для запитаного ресурсу, і 501 (Не реалізовано, Not Implemented), якщо метод не розпізнано або реалізований сервером. Список методів, відомих серверу, то, можливо зазначений на полі заголовка відповіді Public.

Методи GET і HEAD повинні підтримуватися усіма універсальними (generalpurpose) серверами. Інші методи опциональны.

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

URI запиту (Request-URI) — це Однаковий Ідентифікатор Ресурсу (URL), який ідентифікує ресурс запроса.

Request-URI = «* «| absoluteURI | abs_path.

Три опції для URI запиту (Request-URI) залежить від характеру запиту. Зірочка «* «означає, що запитує не специфічний ресурс, а сервер безпосередньо, і допустимий лише у разі, коли використовуваний метод необов’язково звертається до ресурсу. Як примера:

OPTIONS * HTTP/1.1.

absoluteURI необхідний, коли запит виробляється через прокси-сервер. Прокси-сервер перенаправляє запит на сервер чи обслуговує його, користуючись кэшем, і повертає відповідь. Прокси-сервер може переслати запит іншому прокси-серверу чи серверу, певному absoluteURI. Щоб уникнути зациклення запиту прокси-сервер може бути здатний розпізнавати все імена серверу, включаючи будь-які псевдоніми, локальні різновиду, і числові IP адреси. Request-Line то, можливо, наприклад, таким:

GET internet HTTP/1.1.

Щоб якось забезпечити перехід до absoluteURI переважають у всіх запитах в майбутніх версіях HTTP, все HTTP/1.1 серверу враховували absoluteURI в запитах, хоча HTTP/1.1 клієнти будуть генерувати їхньому народові тільки в запитах до проксисерверам.

Найбільш загальна форма Request-URI використовується для ідентифікації ресурсу початковому сервері чи шлюзі. І тут абсолютний шлях URI має бути переданий як Request-URI, а мережне розташування URI (net_loc) має має бути передане на полі заголовка Host. Для останнього прикладу клієнт, бажаючий отримати ресурс безпосередньо з початкового серверу повинен створити TCP з'єднання 80 порт хоста «internet і послати строки:

GET /pub/WWW/TheProject.html HTTP/1.1 Host: internet.

і далі залишок запиту. Абсолютний шлях може бути порожнім; якщо оригінальний URI порожній, він повинен запрашиваться як «/ «(кореневої каталог сервера).

Якщо прокси-сервер отримує запит без шляху до Request-URI, і метод запиту допускає форму запиту «* », то останній прокси-сервер в ланцюжку запитів повинен передати запит, у якому Request-URI дорівнює «* ». Наприклад запрос.

OPTIONS internet HTTP/1.1.

был б переданий прокси-сервером в виде.

OPTIONS * HTTP/1.1 Host: internet.

после з'єднання з портом 8001 хоста «internet.

Початковий сервер повинен декодировать Request-URI, щоб правильно інтерпретувати запит. Серверам сдледует відповідати на неприпустимі RequestURI відповідним кодом состояния.

У запитах, пересланих прокси-сервером, частина «abs_path «URI запиту (Request-URI) будь-коли повинна перезаписываться, крім випадку, відзначеного вище, коли порожній abs_path замінюється на «* », незалежно від внутрішньої реалізації прокси-сервера.

Правило «ніщо не перезаписувати «охороняє проксі-сервера від зміни значення запиту, у якому початковий сервер неправильно використовує не зарезервовані символи URL на свої целей.

5.2 Ресурс, идентифицируемый запросом.

Початкові HTTP/1.1 серверу повинні враховувати, що точний ресурс, идентифицируемый интернет-запросом визначається шляхом дослідження цього URI (Request-URI) і ниви заголовка Host.

Початковий сервер, який розрізняє ресурси по запитаному хосту (host), може ігнорувати значення поля заголовка Host.

Початковий сервер, який розрізняє ресурси виходячи з запитаного хоста (host) (іноді звані віртуальними хостами чи 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 | Accept-Charset | Accept-Encoding | Accept;

Language | Authorization | From | Host | If-Modified-Since | If-Match.

| If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards |.

Proxy-Authorization | Range | Referer | User-Agent.

Багато імен полів заголовка запиту (Request-header) то, можливо надійно розширене лише у поєднані із зміною версії протоколу. Проте, нові чи експериментальні поля заголовка можуть одержати семантику полів заголовка запиту (Request-header), коли всі боку сполуки розпізнають їх як поля заголовка запиту (Request-header). Нерозпізнані поля заголовка обробляються як поля заголовка об'єкта (entity-header).

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

Після набуття і інтерпретації повідомлення запиту, сервер відповідає повідомленням HTTP ответа.

Response = Status-Line *(general-header | response-header | entityheader) CRLF [ message-body ].

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 значень першої цифры:

— 1xx: Інформаційні коди — запит отримано, триває обработка.

— 2xx: Успішні коди — дію було успішно отримано, зрозуміло і обработано.

— 3xx: Коди перенаправлення — до виконання запиту би мало бути вжито подальші действия.

— 4xx: Коди помилок клієнта — запит має поганий синтаксис або то, можливо выполнен.

— 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 | Location | Proxy-Authenticate | Public | Retry;

After | Server | Vary | Warning | WWW-Authenticate.

Багато імен полів заголовка відповіді (Response-header) то, можливо надійно расширенО лише у поєднані із зміною версії протоколу. Проте, нові чи експериментальні поля заголовка можуть одержати семантику полів заголовка відповіді (Response-header), коли всі боку сполуки розпізнають їх як поля заголовка відповіді (Response-header). Нерозпізнані поля заголовка обробляються як поля заголовка об'єкта (entity-header).

7 Об'єкт (Entity).

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

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

7.1 Поля заголовка объекта.

Поля заголовка об'єкта (Entity-header fields) визначають опціональну метаінформацію про тілі об'єкта (entity-body) чи, якщо тіло відсутня, про ресурсі, идентифицированном запросом.

entity-header = Allow | Content-Base | Content-Encoding | Content;

Language | Content-Length | Content-Location | Content-MD5 | Content;

Range | Content-Type | ETag | Expires | Last-Modified | extensionheader extension-header = message-header.

Механізм розширення полів заголовка дозволяє вводити додаткові поля заголовка об'єкта (entity-header fields) не змінюючи протокол, але це поля можуть і не розпізнані одержувачем. Одержувач має ігнорувати нерозпізнані поля заголовка, а прокси-сервер повинен просто пересилати їх без изменений.

7.2 Тіло объекта.

Тіло об'єкта (коли вона присутній) посилається з HTTP запитом чи відповіддю і має формат і кодування, обумовлений полями заголовка об'єкта (entity-header fields).

entity-body = *OCTET.

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

7.2.1 Тип.

Коли повідомленні міститься тіло об'єкта (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 Длина.

Довжина тіла об'єкта (entity-body) — це довжина тіла повідомлення (messagebody), отриманого після декодування всіх кодувань передачи.

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

8.1 Постійні сполуки (Persistent Connections).

8.1.1 Цель.

До запровадження протокол постійних сполук для запиту кожного URL встановлювалося окреме TCP з'єднання, що збільшувала навантаження на HTTP серверу та викликало перевантаження мереж. Використання вбудованих зображень і інших пов’язаних даних часто жадає від клієнта ініціювати кілька запитів одного серверу за стислий період времени.

Постійні HTTP сполуки випливає низка преимуществ:

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

— HTTP запити, й відповіді то, можливо конвейеризованы в соединении.

Конвеєрна обробка дозволяє клієнту робити кілька запитів без вичікування відповіді кожен, дозволяє користуватися єдиним TCP з'єднанням ефективніше, з меншими витратами времени.

— Завантаження мережі зменшується із зменшенням числа пакетів, необхідні відкриття TCP сполук, і, отже, надає протоколу TCP достатньо часу визначення стану перевантаження сети.

— HTTP може розвиватися елегантніше; оскільки помилки можна повідомляти без закриття TCP з'єднання перетворені на ролі штрафу. Клієнти, використовують майбутні версії 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, то запит стає останнім в соединении.

Щоб з'єднання залишалося постійним, все повідомлення, передані по нього мають мати самоопределенную (self-defined) довжину (тобто, не котру визначаємо закриттям соединения).

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

Клієнт, що підтримує постійні сполуки вміє виробляти «конвеєрну обробку «запитів (тобто посилати кілька запитів не очікуючи відповіді кожен із новачків). Сервер повинен послати відповіді ці запити у тому самому порядку, що не отримано запросы.

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

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

Дуже важливо було, щоб проксі-сервера правильно реалізовували властивості полів заголовка Connection.

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

Прокси-сервер ні встановлювати постійних сполук з HTTP/1.0 клиентом.

8.1.4 Практичні соображения.

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

Коли в клієнта чи серверу минув час очікування, він повинен зробити закриття транспортного сполуки. Як клієнтам, і серверам слід постійно стежити іншим боком щодо закриття з'єднання заліза і відповідати відповідно. Якщо клієнт чи сервер не відразу виявляє закриття сполуки іншим боком, це викликає не виправдану трату ресурсів сети.

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

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

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

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

8.2 Вимоги до передавання сообщений.

Загальні требования:

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

— HTTP/1.1 (чи більше пізнім) клієнтам, посылающим тіло сообщения.

(message-body) слід контролювати мережне з'єднання предмет помилок під час передачі запиту. Якщо клієнт виявляє помилку, йому слід негайно припинити передачу тіла повідомлення. Якщо тіло посилається з допомогою кодування «шматками «(«chunked »), то шматок нульової довжини, і порожній завершувач можна використовувати для індикації передчасного кінця повідомлення. Якщо тілу передував заголовок Content-Length, клієнт повинен закрити соединение.

— HTTP/1.1 (або як пізній) клієнт повинен бути готовий прийняти відповідь з кодом стану 100 (Продовжувати, Continue), попередній основному ответу.

— HTTP/1.1 (чи більше пізній) сервер, котра отримує запит от.

HTTP/1.0 (чи більше раннього) клієнта ні відповідати кодом стану 100 (Продовжувати, Continue); йому слід або чекати, поки запит буде виконано звичайним чином (тобто без використання перерваного запиту), або передчасно закрити соединение.

— Після набуття методу, підлеглого наведеним вимогам, від HTTP/1.1.

(чи більше пізнього) клієнта, HTTP/1.1 (або як пізній) сервер повинен або відповісти кодом стану 100 (Продовжувати, Continue) і продовжувати читання вхідного потоку, або відповісти кодом стану помилки. Якщо сервер відповів кодом стану помилки, він може або закрити транспортне з'єднання (TCP), або продовжувати читати і відкидати решту запиту. Він має виконувати запитаний метод, якщо повернув код стану ошибки.

Клієнтам слід номер версії HTTP, використовуваної сервером по крайнього заходу востаннє; якщо HTTP/1.1 клієнт зустрічав HTTP/1.1 чи пізніший відповідь від серверу, і якими бачить закриття сполуки перед отриманням будь-якого коду стану від серверу, клієнту слід повторити запит без взаємодії з користувачем, якщо метод запиту идемпотентен; інші методи нічого не винні бути повторені автоматично, хоча агенти користувача можуть оператору повторити запит. Якщо клієнт повторює запит, то он.

— повинен спочатку послати поля заголовка запиту, а затем.

— повинен або чекати відповіді серверу з кодом 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 реалізована сервером, якщо клієнт отримує код стану помилки, то он.

— ні продовжувати и.

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

HTTP/1.1 (або як пізнього) клієнту, який виявляє закриття сполуки після відповіді з кодом стану 100 (Продовжувати, Continue), але до відповіді з іншим кодом стану, слід повторити запит, але вже очікувати відповіді з кодом стану 100 (Продовжувати, Continue).

9 Визначення методов.

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

Поле заголовка запиту Host має супроводжувати все HTTP/1.1 запросы.

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

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

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

Зокрема було винесено угоду, що методи GET і HEAD будь-коли повинен мати іншого значення, крім завантаження (retrieval). Ці методи слід розглядати, як «безпечні «. Це дозволяє агенту користувача представляти інші методи, такі як POST, PUT і DELETE, в такий спосіб, щоб користувач знав у тому, що він затребувана виконання потенційно небезпечного действия.

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

9.1.2 Идемпотентные методы.

Методи можуть також мати властивістю «идемпотентности «(«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, IfMatch, If-None-Match, чи If-Range. Умовний метод GET затребувана передачу об'єкта, лише коли останній задовольняє умовам, описаним в умовних полях заголовка. Умовний метод GET призначений зменшення невиправданою завантаження мережі, і дозволяє оновлювати кэшированные об'єкти без використання кількох запитів чи пересилки даних, вже збережених клиентом.

Різниться також «частковий GET «(«partial GET »), у якому повідомлення запиту включає полі заголовка Range. Частковий GET затребувана передачу лише частини об'єкта. Частковий метод GET призначений для зменшення непотрібної завантаження мережі, і дозволяє збирати об'єкти з двох частин, без передачі частин даних, вже збережених клиентом.

Відповідь на запит GET кэшируем тоді й тільки тоді, що він відповідає вимогам кэширования в HTTP, описаним ниже.

9.4 HEAD.

Метод HEAD ідентичний GET, крім те, що сервер ні повертати у відповідь тіло повідомлення (message-body). Метаинформации, котра міститься в HTTP заголовках відповіді запит HEAD треба бути ідентичною інформації, представленої у відповідь запит GET. Цей метод можна використовувати щоб одержати метаинформации об'єкт запиту без безпосередньої пересилки тіла об'єкта (entity-body). Цей метод часто використовується для тестування гіпертекстових зв’язків з метою перевірки достовірності, досяжності, і часу модификации.

Відповідь на запит HEAD то, можливо кэшируемым тому, що інформація, у відповіді можна використовувати для модифицикации попередньо кэшированного об'єкта від цього ресурсу. Якщо нових значень поля вказують, що кэшируемый об'єкт відрізняється від того плинного об'єкта (по таким параметрами, як Content-Length, Content-MD5, ETag чи Last-Modified), то кеш повинен обробляти вміст як просроченное.

9.5 POST.

Метод POST використовується для запиту, у якому адресуемый сервер приймає об'єкт, включений у запит, як «Нове підпорядкування (subordinate) ресурсу, ідентифіковану запрашиваемым URI (Request-URI) в рядку запиту (Request-Line). POST розроблений у тому, щоб загальним методом реалізувати такі функции:

— Анотація існуючих ресурсов;

— Реєстрація повідомлення в електронній дошці оголошень (bulletin board), в конференції новин (newsgroup), списку розсилки (mailing list), чи як і групі статей;

— Передача блоку даних, наприклад результат входження у формі, процесу обработки;

— Розширення бази даних з допомогою конкатенирующей операції (append operation).

Фактично функція, виконувана методом POST, визначається сервером і зазвичай залежить від цього URI (Request-URI). Об'єкт, рухаючись методом POST, належить до цього URI як і файл належить до каталогу, в якій він перебуває, стаття належить до конференції новин (newsgroup), де вона зареєстровано, а запис належить до бази данных.

Дія, яке виконує методом POST може давати як результату ресурс, який можна б ідентифікувати URI. У цьому вся разі, залежно від цього, включає чи відповідь об'єкт, описує результат, чи ні, код стану у відповідь може бути як 200 (OK), і 204 (Ні вмісту, No Content).

Якщо ресурс створили початковому сервері, відповіді слід утримувати код стану 201 (Створено, Created) і включатимуть об'єкт, який описує стан запиту і називає новий ресурс, і навіть заголовок Locatio.

Відповіді цей метод не кэшируемы, якщо відповідь не включає відповідні поля заголовка Cache-Control чи Expires. Проте відповіді з кодом стану 303 (Дивитися інший, See Other) можна використовувати для перенаправлення агента користувача для завантаження кэшируемого ресурса.

Запити POST повинні відповідати вимогам передачі сообщения.

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 може позначитися деяких інших URI, певних початковою сервером.

HTTP/1.1 не визначає як метод PUT впливає на стан початкового сервера.

Запити PUT мають підкорятися вимогам передачі сообщений.

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 в запиті. Запит TRACE ні утримувати объекта.

TRACE дозволяє клієнту побачити, що іншому кінці ланцюжка запитів і використовувати ці дані для тестування чи діагностичної інформації. Значення поля заголовка Via представляє особливий інтерес, бо вона діє і як слід ланцюжка запитів. Використання поля заголовка Max-Forwards дозволяє клієнту обмежувати довжину ланцюжка запитів, що корисно під час тестування нескінченних циклів у ланцюжку проксисерверів, пересылающих повідомлення. Якщо запит виконано успішно, то відповіді слід утримувати все повідомлення запиту у тілі об'єкта (entity-body), а Content-Type треба бути рівним «message/http ». Відповіді цей метод нічого не винні кэшироваться.

10 Визначення кодів состояния.

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

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, указывающее бажаний діапазон. Відповідь має утримувати або полі заголовка Content-Range, указывающее діапазон, включений у відповідь, або тип вмісту (Content-Type) має бути однаковим «multipart/byteranges », а поля Content-Range мають утримуватися у кожному частини. Якщо «multipart/byteranges «немає, полі заголовка ContentLength у відповідь ПОВИННО відповідати фактичному числу октетів (OCTETs), переданих тілі повідомлення (message-body). Кеш, який підтримує заголовки Range і Content-Range ні кэшировать відповіді з кодом стану 206.

10.3 3xx — Перенаправление.

Цей клас кодів стану вказує, що з виконання запиту агенту користувача необхідно придпринять додаткове дію. Необхідну дія може відбуватися виконати агентом користувача без взаємодії з користувачем, тоді й тільки тоді, коли у другому запиті використовується метод GET чи HEAD. Агенту користувача годі було автоматично спрямовуватиме запит понад п’ять отже як такі переадресації зазвичай вказують нескінченний цикл.

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

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

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

Відповідь має утримувати такі поля заголовка:

— Date.

— ETag і/або Content-Location, якщо заголовок було б посланий у відповідь з кодом стану 200 цей самий запрос.

— Expires, Cache-Control, і/або Vary, якщо значення поля (field-value) може відрізнятиметься від посланого у кожному попередньому відповіді для такої ж варианта.

Якщо умовний GET використовує суворе порівняння кешу (strong cache validator), то відповіді годі було утримувати інших заголовків об'єкта (entity-headers). Інакше (тобто, якщо умовний GET використовує слабке порівняння (weak validator)) відповідь ні утримувати інших заголовків об'єкта; це запобігає неузгодженості між кэшированными тілами об'єктів (entity-bodies) і модифікованими заголовками.

Якщо відповідь з кодом стану 304 вказує об'єкт, нині не кэшированный, то кеш повинен ігнорувати відповідь і повторити запит без умовного висловлювання. Якщо кеш використовує отриманий відповідь з кодом стану 304 для модифицикации входження кешу, кеш повинен модифікувати входження так, аби відбити будь-які нових значень полів, дані у відповідь. Відповідь із кодом стану 304 ні включати тіла повідомлення (messagebody), отже, завжди завершується першої порожній рядком після полів заголовка.

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, що містить виклик (challenge), який можна застосовувати до запитаному ресурсу. Клієнт може повторити запит з підхожим полем заголовка Authorization. Якщо запит вже включає рекомендації встановлення дійсності (Authorization credentials) на полі Authorization, то відповідь з кодом стану 401 вказує, що у встановленні дійсності цим рекомендаціям відмовлено. Якщо відповідь з кодом стану 401 містить той самий виклик, як і попередній відповідь, а агент користувача вже намагався встановлення дійсності по крайнього заходу одного разу, слід показати користувачеві об'єкт, який дали в відповіді, тому що цей об'єкт може охоплювати актуальну діагностичну информацию.

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, що містить виклик (challenge), застосовуваний прокси-сервером для запитаного ресурсу. Клієнт може повторити запит з підхожим полем заголовка Proxy-Authorization.

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 версію, як і клієнт (крім цих слів). Відповіді слід залучити об'єкт, описує, чого ця версія не підтримується, і які інші протоколи підтримуються цим сервером.

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 (canonical root URL) серверу, якого звернений запит, ідентифікує захищену область (protection space). Ці області дозволяють розбивати захищені ресурси серверу силою-силенною областей, кожна з яких має власну схему встановлення дійсності і/або базі даних авторизації (authorization database). Значення realm — це рядок, власне кажучи призначена початковою сервером, яка може мати додаткову семантику, специфічну для схеми встановлення подлинности.

Агент користувача, що хоче довести свою справжність серверу, зазвичай, але, може зробити після відповіді з кодом стану 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 нетронутыми.

HTTP/1.1 дозволяє клієнту передавати інформацію встановлення дійсності для і південь від проксі-сервера у вигляді заголовків ProxyAuthenticate і 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==.

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

Scheme) [1].

13 Кэширование в HTTP.

HTTP зазвичай використовується для розподілених інформаційних систем, ефективність яких можна поліпшити під час використання кэшированных відповідей. Протокол HTTP/1.1 включає низку елементів, запропонованих як можлива реалізація кэширования. Оскільки ці елементи від інших аспектів протоколу, й, оскільки вони взаємодіють друг з одним, то корисно буде описати основи кэширования в HTTP окремо від деталізованих описів методів, заголовків, кодів стану, і прочего.

Мета кэширования в HTTP/1.1 у тому, щоб негайно усунути потреба посилки запитів у часто, і усунути потреба посилки повних відповідей за іншими випадках. Кэширование зменшує число пересилань інформації через мережу, необхідних багатьох дій; ми використовуємо цієї мети механізм «устаревания «(«expiration »). Кэширование знижує вимоги до пропускну здатність мережі; ми використовуємо цієї мети механізм «перевірки достовірності «(«validation »).

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

— Тільки явним запитом лише на рівні протоколу якщо ослаблення викликається клієнтом чи початковою сервером.

— Тільки із явним попередженням кінцевого користувача якщо ослаблення викликається кэшем чи клиентом.

Отже протокол HTTP/1.1 надає такі важливі элементы:

1. Можливості протоколу, що забезпечують повну семантичну прозорість коли це потрібно всім сторонам.

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

3. Можливості протоколу, що дозволяють кэшу приєднувати до відповідей попередження тому, що запитаний рівень семантичної прозорості не сохранен.

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

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

13.1 Загальна інформацію про кэшировании.

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

Правильний кеш повинен відповідати на запит найсучаснішим відповіддю, відповідним запиту, зі збережених кэшем який задовольняє одного з наступних условий:

1. Він перевірив на еквівалентність відповіді, який повернув початковий сервер, повторно підтверджуючи достоверность;

2. Він «досить свіжий «(«fresh enough »). За умовчанням це, що він задовольняє найменшій з обмежувальних вимог свіжості клієнта, серверу та кешу; якщо така визначено початковою сервером, це — вимога свіжості єдино початкового сервера.

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

4. Він відповідає повідомленню відповіді з кодом стану 304 (не модифікований, Not Modified), 305 (використовуйте прокси-сервер, Use.

Proxy), чи хибному відповіді (4xsx чи 5xx).

Якщо кеш неспроможна зв’язатися з початковою сервером, то правильному кэшу слід відповідати як описано вище, якщо відповідь то, можливо правильно обслужен з кешу; інакше необхідно повернути помилку чи попередити про тому, що є відмова связи.

Якщо кеш отримує відповідь (або весь відповідь, або відповідь з кодом стану 304 (не модифікований, Not Modified)), що може бути нормально переданий запрашивающему клієнту, і отриманий відповідь застарів, то кэшу слід переслати його запрашивающему клієнту не додаючи нового заголовка Warning (Попередження) (але з видаляючи існуючі заголовки Warning). Кэшу не варто намагатися повторно перевірити достовірність відповіді уже тому, що той відповідь застарів під час передачі; це могло призвести до нескінченному циклу. Агент користувача, котра отримує прострочений відповідь без Warning може показати користувачеві предупреждение.

13.1.2 Предупреждения.

Щоразу, коли кеш повертає відповідь, який є ні безпосереднім (first-hand), ні «досить свіжим «(себто умови 2 розділу 13.1.1), він має приєднати попередження звідси, використовуючи заголовок відповіді Warning. Це попередження дозволяє клієнтам робити відповідні действия.

Попередження можна використовувати з метою, як що з кэшированием, не пов’язаних. Використання попереджень, а чи не хибних кодів стану, відрізняє ці відповіді істинних отказов.

Попередження кэшируемы завжди, бо послаблюють прозорість відповіді. Це означає, що попередження можуть бути HTTP/1.0 кэшам без побоювань; такі кэши просто передадуть попередження далі як заголовок об'єкта в ответе.

Попередження — це визначені числа від 0 до 99. Ця специфікація визначає коди, і значення кожного певного на цей час попередження, дозволяючи клієнту чи кэшу робити самостійні дії деяких (але в всіх) случаях.

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

До відповіді може бути приєднано кілька попереджень (як початковою сервером, і кэшем), включаючи кілька попереджень з одиннаковыми кодовими номерами. Наприклад, сервер може додавати те й теж попередження як до англійським текстам, і до баскским.

Якщо до відповідальності долучено кілька попереджень, вона може бути мало доцільно або прийнятно показати всі вони користувачеві. Ця версія HTTP не визначає суворих пріоритетних правил для визначення, які з попереджень представляти і у порядку, але пропонує деяку эвристику.

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

Основні механізми кешу в HTTP/1.1 (зазначені сервером час устаревания (expiration time) і покажчик достовірності (validator)) — неявні директиви кэшу. Можливі випадки, у яких сервер чи клієнт повинен забезпечити явні директиви HTTP кэшу. Ми використовуємо цієї мети заголовок Cache-Control.

Заголовок Cache-Control дозволяє клієнту чи серверу передавати ряд директив як і запитах, і у відповідях. Ці директиви зазвичай скасовують испоьзуемые за умовчанням кэширующие алгоритми. Як загальне правило: якщо є очевидний конфлікт між значеннями заголовка, має застосовуватися найбільш що обмежує інтерпретація (тобто та, яка, найкраще збереже семантичну прозорість). Однак у деяких випадках директиви управління кэшем (Cache-Control) явно вказують ослаблення рівня семантичної прозорості (наприклад, «максимальнопрострочений «(«max-stale ») чи «загальний «(«public »)).

13.1.4 Явні попередження агента пользователя.

Багато агенти користувача дають можливість для користувачів скасувати основні механізми кэширования. Наприклад агент користувача можуть дозволити користувачеві вказати таку поведінку, у якому кэшированные об'єкти (навіть явно прострочені) будь-коли перевіряються на достовірність (are never validated). Або агент користувача міг би додавати «Cache-Control: maxstale=3600 «до кожного запиту. Користувачу слід явно вимагати як надання у непрозорий поведінка, і поведінка, яке не так призводить до неефективного кэшированию.

Якщо користувач скасував основні механізми кэширования, агент користувача повинен явно інформувати користувача щоразу, коли відбувається відображення інформації, яка може задовольняти вимогам прозорості серверу (зокрема якщо відомо, що відображуваний об'єкт прострочений). Оскільки протокол зазвичай дозволяє агенту користувача визначити, прострочені відповіді чи ні, то індикація необхідна тільки тоді ми, коли це відбувається. Це може позначатися не лише діалоговим вікном, а й іконкою (наприклад, зображенням гниючої риби) або іншими візуальним индикатором.

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

13.1.5 Винятки з правив і предупреждений.

У окремих випадках, оператор кешу може сконфигурировать її такою чином, що він повертав прострочені відповіді, навіть якщо де вони вимагають клієнтами. Це рішення має зроблено легко, але то, можливо необхідно з причин доступності чи ефективності, особливо, коли кеш має прохое з'єднання з початковою сервером. Щоразу, коли кеш повертає прострочений відповідь, він має позначити його (використовуючи заголовок Warning). Це дозволяє програмному забезпеченню клієнта попереджати користувача, що можна є потенційна проблема.

І це дозволяє агенту користувача вживати заходів для отримання безпосереднього (first-hand) чи свіжого відповіді. З цієї причини, кэшу годі було повертати прострочений відповідь, якщо клієнт явно затребувана безпосередній чи свіжий, крім випадків, коли це неможливо виконати з технічних чи стратегічним причинам.

13.1.6 Контрольоване клієнтом поведение.

Тоді як початковий сервер (і меншою мірою проміжні кэши зі своїми внеском в вік відповіді) є первинним джерелом інформацію про устаревании, деяких випадках клієнту то, можливо необхідно управляти рішенням кешу у тому, повертати чи кэшированный відповідь, не перевіряючи його достовірність. Клієнти роблять це використовуючи кілька директив заголовка управління кэшем (Cache-Control). Запит клієнта може визначати максимальний вік неутвержденного відповіді, що він бажає одержати; вказуючи нуль він змушує кэш (и) перевірити ще раз достовірність всіх відповідей. Клієнт може також визначити мінімальне час які мають пройти доти, як застаріє. Обидві цих опції збільшують обмеження на поведінка кэшей, отже, не можуть далі послабляти рівень семантичної прозорості кэша.

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

13.2 Модель устаревания.

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

HTTP кэширование працює найкраще тоді, коли кэши можуть убереже від запитів до початкового серверу. Первинний механізм звільнення від запитів — коли сервер походження забезпечує явне час устаревания у майбутньому, вказуючи, відповідь можна використовувати для задоволення наступних запитів. Інакше кажучи, кеш може повертати свіжий відповідь без контакту з сервером.

Ми сподіваємося, що сервери будуть призначати явне час устаревания відповідей будучи переконані, що об'єкт, мабуть, нічого очікувати змінено семантично значимим способом до закінчення цього часу. Це зазвичай зберігає семантичну прозорість, якщо час устаревания старанно вибрано сервером.

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

Якщо початковий сервер хоче змусити семантично прозорий кеш перевіряти достовірність кожного запиту, може явно вказати час устаревания у минулому. Це означає, відповідь завжди прострочений, і такою чином, кеш повинен перевіряти його достовірність перед використанням для наступних запросов.

Якщо початковий сервер хоче змусити будь-який HTTP/1.1 кеш, незалежно від цього, як і сконфигурирован, перевіряти достовірність кожного запиту, він має використовувати директиву Cache-Control «must-revalidate » .

Сервери вказують явне час устаревания, використовуючи як заголовок Expires, і директиву max-age заголовка Cache-Control.

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

13.2.2 Евристичне устаревание.

Оскільки початкові сервери який завжди вказують явне час устаревания, то HTTP кэши зазвичай призначають евристичне час устаревания, використовуючи алгоритми, що використовують значення інших заголовків (таких як час останнього модифікації (Last-Modified)) з оцінки ймовірного часу устаревания. Специфікація HTTP/1.1 не забезпечує специфічних алгоритмів, але накладає обмеження як оцінки найгіршою похибки їх роботи. Оскільки евристичне часу устаревания має зберігати під загрозу семантичну прозорість, вони повинні використовуватися обережно, і ми заохочуємо початкові сервери вказувати явне час устаревания наскільки можливо часто.

13.2.3 Обчислення возраста.

Щоб знати, чи є що міститься у кэше об'єкт свіжим, кеш повинен знати, перевищує його вік термін свежести.

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

HTTP/1.1 вимагає, щоб початкові сервери посилали у кожному відповіді заголовок Date, що дає час, коли було сгенерирован ответ.

HTTP/1.1 використовує заголовок відповіді Age передачі інформації про віці між кэшами. Значення заголовка Age є оцінкою відправника кількості часу, минулого з, коли відповідь був сгенерирован на початковому сервері. Що стосується кэшированного відповіді, який був повторно підтверджено початковою сервером, значення Age виходить з часу переперевірки достовірності, а чи не на часу початкового ответа.

По суті, значення Age — сума часів які відповідь був у кожному з кэшей шляхом від початкового серверу та часів передачі по сети.

Вік відповіді то, можливо вирахувано двома цілком незалежними способами:

1. «Зараз «мінус date_value, якщо локальні годинник добре синхронізовані з годинниками початкового серверу. Якщо результат негативний, результат замінюється нулем.

2. age_value, коли всі кэши шляхом відповіді реалізують HTTP/1.1.

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

Corrected_received_age = max («зараз «- date_value, age_value).

і що годинник ми синхронізовані, проте кэши по дорозі відповіді - HTTP/1.1, отримуємо надійний (консервативний) результат.

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

Через затримок, обумовлених мережею, деяке чимало часу може пройти між моментом, коли сервер сгенерировал відповідь і моментом, коли його отримано наступним зовнішнім кэшем чи клієнтом. Ігнорування цієї затримки, спричинить неправильно низьким возрастам.

Якщо запит, який привів до повернутому значенням Age, має бути був инициализирован до породження значень Age, ми можемо виправляти накладені мережею затримки, роблячи запис часу, коли було сгенерирован запит. Отже, коли отримано значення Age, вона має бути інтерпретоване щодо часу, коли було сгенерирован запит, а чи не щодо часу, коли було отримано відповідь. Цей алгоритм призводить до консервативному поведінці незалежно від цього, як і затримка. Вычисляем:

corrected_initial_age = corrected_received_age + («зараз «- request_time).

Де «request_time «- час (відповідно до локальним годинах), коли було посланий запит, що викликав даний ответ.

Резюме алгоритму обчислення віку отриманого кэшем відповіді: /* * age_value * - це значення Age: заголовок, отриманий кэшем в * цьому відповіді. * date_value * - це значення Date початкового серверу: заголовок * request_time * - це (локальне) времея, коли кеш зробив запит, * що викликало цей кэшируемый відповідь * response_time * - це (локальне) час, коли кеш почув у відповідь * now * - поточне (локальне) час */ apparent_age = max (0, response_time — date_value); corrected_received_age = max (apparent_age, age_value); response_delay = response_time — request_time; corrected_initial_age = corrected_received_age + response_delay; resident_time = now — response_time; current_age = corrected_initial_age + resident_time;

Коли кеш посилає відповідь, він має додати corrected_initial_age кількість часу, яке відповідь утримувався у ньому. Вони повинні потім передати цей загальний вік, використовуючи заголовок Age, наступному котра отримує кэшу.

13.2.4 Обчислення устаревания.

Щоб решить, является чи відповідь свіжим чи простроченим, ми повинні порівняти його служби із віком. Вік обчислюється за алгоритмом, описаного розділ 13.2.3, і той розділ описує, як обраховувати термін служби, та імідж визначатимуть, не застарів чи відповідь. Наступного описі значення можуть представлятися у будь-якій формі, підходить арифметичних действий.

Термін «expires_value «представляє значення заголовка Expires. Термін «max_age_value «застосовується для вказівки значення числа секунд, що був директивою max-age заголовка Cache-Control ответа.

Директива max-age має пріоритет над Expires. Отже тоді як відповіді присутній max-age, то обчислення просты:

freshness_lifetime = max_age_value.

За інших випадках, як у відповіді присутній Expires, обчислення таковы:

freshness_lifetime = expires_value — date_value.

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

Якщо ні Expires, ні Cache-Control: max-age невідомі у відповідь, і відповідь зовсім позбавлений інших кэширования, то кеш може обчислити термін їхньої служби, використовуючи евристику. Якщо це значення більше 24-х годин, то кеш повинен приєднувати Warning 13 до будь-якого відповіді, вік яких більше 24-х годин, коли таке попередження не було добавлено.

Також якщо відповідь має час останнього зміни Last-Modified, то эвристическому значенням часу устаревания слід сприймати значення не більш певної частини тимчасового інтервалу, минулого цього часу. Типова значення цієї маленької частини міг стати 10%. Обчислити, сплив відповідь, цілком просто: response_is_fresh = (freshness_lifetime > current_age).

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

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

Якщо клієнт, виконує пошук, отримує не безпосередній у відповідь запит, що був свіжим у його власному кэше, а заголовок Date в існуючому входження кешу свіжіший, ніж Date нового відповіді, то клієнт може ігнорувати відповідь. Якщо він ігнорує відповідь, він може повторити запит із директивою «Cache-Control: max-age=0 », викликаючи перевірку початковою сервером.

Якщо кеш має дві свіжих відповіді запит однієї й тієї ж уявлення, але з різними покажчиками достовірності, він повинен використовувати той із них, яка має заголовок Date більш свіжий. Така ситуація може вознкнуть або коли кеш об'єднує відповіді інших кэшей, або коли клієнт запросив перезавантаження чи перепроверку достовірності очевидно свіжого входження кэша.

13.2.6 Усунення протиріч між кількома ответами.

Через те, що тут клієнта може отримувати відповіді багатьма шляхами, можлива ситуація, коли кеші отримує один потік відповідей через один набір кэшей, а інший потік відповідей через інший набір кэшей. У разі клієнт може отримувати відповіді гаразд, відмінному від цього, у якому їх посилав початковий сервер. Ми хотів би, щоб клієнт використовував найбільш свіжий відповідь, навіть адже раніше отримані відповіді досі очевидно свежи.

Ні мітка об'єкта ні значення устаревания не можгут бути використані для упорядкування відповідей, оскільки, можливо, пізніший відповідь навмисно несе більш ранніх час устаревания. Проте, специфікація HTTP/1.1 вимагає передачі заголовків Date у кожному відповіді, і значення Date упорядковують ступінь деталізації до секунды.

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

Cache-Control: max-age=0.

щоб змусити проміжні кэши перевірити достовірність їх копій безпосередньо початковою сервером, или.

Cache-Control: no-cache.

щоб змусити проміжні кэши здобути новий копію з початкового сервера.

Якщо значення Date рівні, то клієнт може використовувати будь-який відповідь (чи може, коли він надзвичайно завбачливий, запросити новий відповідь). Сервери нічого не винні покладатися те що, що клієнти здатні вибрати між відповідями, породженими протягом одного секунди, якщо їх часи устаревания накладываются.

13.3 Модель перевірки достовірності (validation model).

Якщо кеш має просроченное входження, що він хотілося б використовувати як відповіді запит клієнта, він повинен звіритися з початковою сервером (чи з проміжним кэшем, які мають свіжим відповіддю) щоб отримати, чи є входження кешу досі придатним від використання. Ми називаємо це «перевіркою достовірності «входження кешу. Оскільки не хочемо оплачувати надмірну передачу повного відповіді, коли кэшируемый нас влаштовує, й, оскільки не хочемо оплачувати зайву передачу відповіді туди, й назад, коли кэшируемое входження нас потребу не влаштовує, протокол HTTP/1.1 підтримує використання умовних методов.

Ключові можливості протоколу задля забезпечення умовних методів — ті, які мають ставлення до «покажчикам достовірності (validators) кешу ». Коли початковий сервер генерує повний відповідь, він приєднує щодо нього певний покажчик достовірності (validator), який зберігається у входження кешу. Коли клієнт (агент користувача чи кеш проксі-сервера) робить умовний запит на ресурс, котрій вона має входження кешу, він включає пов’язаний покажчик достовірності (validator) в запрос.

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

У HTTP/1.1, умовний запит виглядає так само, як нормальна запит тієї самої ресурсу, крім те, що він містить спеціальний заголовок (що включає покажчик достовірності), який неявно перетворює метод (зазвичай, GET) в условный.

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

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

Бібліографічний список.

|Номер |Назва |Автори |Дата |Статус |Примітки | |RFC | | | | | | |822 |STANDARD FOR THE |David H. |August 13,|Proposed |Obsoletes: | | |FORMAT OF ARPA |Crocker |1982 |Standard |RFC #733 | | |INTERNET TEXT | | | | | | |MESSAGES | | | | | |850 |Standard for |RFC team |June 1983 |Information| | | |Interchange of USENET| | |al | | | |Messages | | | | | |1036 |Standard for |M. |December |Proposed |Obsoletes: | | |Interchange of USENET|Horton, |1987 |Standard |RFC-850 | | |Messages |R. Adams | | | | |1123 |Requirements for |Robert |October |Proposed | | | |Internet Hosts — |Braden |1989 |Standard | | | |Application and | | | | | | |Support | | | | | |1738 |Uniform Resource |Tim |December |Proposed | | | |Locators (URL) |Berners-L|1994 |Standard | | | | |її, | | | | | | |Larry | | | | | | |Masinter,| | | | | | | | | | | | | |Mark | | | | | | |McCahill | | | | |1766 |Tags for the |H. |March 1995|Standards | | | |Identification of |Alvestran| |Track | | | |Languages |d | | | | |1808 |Relative Uniform |Roy T. |June 1995 |Proposed | | | |Resource Locators |Fielding | |Standard | | |1867 |Form-based File |E. Nebel,|November |Experimenta| | | |Upload in HTML |L. |1995 |l | | | | |Masinter | | | | |1900 |Renumbering Needs |Brian E. |February |Information| | | |Work |Carpenter|1996 |al | | | | |, Yakov | | | | | | |Rekhter | | | | |1945 |Hypertext Transfer |T. |May 1996 |Information| | | |Protocol — HTTP/1.0 |Berners-L| |al | | | | |її, R. | | | | | | |Fielding | | | | | | |, H. | | | | | | |Frystyk | | | | |1950 |ZLIB Compressed Data |P. |May 1996 |Information| | | |Format Specification |Deutsch, | |al | | | |version 3.3 |J-L. | | | | | | |Gailly | | | | |1952 |GZIP file format |P. |May 1996 |Information| | | |specification version|Deutsch | |al | | | |4.3 | | | | | |2048 |Multipurpose Internet|N. Freed,|November |Best |Obsoletes: | | |Mail Extensions |J. |1996 |Current |1521, 1522, | | |(MIME) Part Four: |Klensin, | |Practice |1590 | | |Registration |J. Postel| | | | | |Procedures | | | | | |2068 |Hypertext Transfer |R. |January |Standards | | | |Protocol — HTTP/1.1 |Fielding,|1997 |Track | | | | | | | | | | | |J. | | | | | | |Gettys, | | | | | | |J. Mogul,| | | | | | |H. | | | | | | |Frystyk, | | | | | | |T. | | | | | | |Berners-L| | | | | | |її | | | | |2069 |An Extension to HTTP |J. |January |Standards | | | |: Digest Access |Franks, |1997 |Track | | | |Authentication |P. | | | | | | |Hallam-Ba| | | | | | |ker, J. | | | | | | |Hostetler| | | | | | |, P. | | | | | | |Leach, A.| | | | | | |Luotonen,| | | | | | |E. Sink, | | | | | | |L. | | | | | | |Stewart | | | |.

———————————;

[pic].

[pic].

[pic].