Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

HTTP



План:

    Введення
    Переваги
    Недоліки і проблеми
    Програмне забезпечення
    Історія розвитку
    Структура протоколу
      .1 Стартова рядок
      .2 Методи
        Приклади діалогів HTTP
        Основні механізми протоколу
          .1 Часткові GET
          .2 Умовні GET
          .3 Узгодження вмісту

          Введення

          HTTP
          Persistence Стиснення SSL
          Заголовки ( список)
          Cookie ETag Referer User-Agent
          Коди стану

          HTTP (скор. від англ. HyperText Transfer Protocol - "Протокол передачі гіпертексту ") - протокол прикладного рівня передачі даних (спочатку - у вигляді гіпертекстових документів). Основою HTTP є технологія "клієнт-сервер", тобто передбачається існування споживачів ( клієнтів), які ініціюють з'єднання і надсилають запит, і постачальників ( серверів), які очікують з'єднання для отримання запиту, роблять необхідні дії і повертають назад повідомлення з результатом. HTTP в даний час повсюдно використовується у Всесвітній павутині для отримання інформації з веб-сайтів. У 2006 році в Північній Америці частка HTTP- трафіку перевищила частку P2P-мереж і склала 46%, з яких майже половина - це передача потокового відео та звуку [1].

          HTTP використовується також в якості "транспорту" для інших протоколів прикладного рівня, таких як SOAP, XML-RPC, WebDAV.

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

          HTTP - протокол прикладного рівня, аналогічними йому є FTP і SMTP. Обмін повідомленнями йде по звичайній схемі запит-відповідь". Для ідентифікації ресурсів HTTP використовує глобальні URI. На відміну від багатьох інших протоколів, HTTP не зберігає свого стану. Це означає відсутність збереження проміжного стану між парами запит-відповідь". Компоненти, що використовують HTTP, можуть самостійно здійснювати збереження інформації про стан, пов'язаної з останніми запитами і відповідями. Браузер, що посилає запити, може відстежувати затримки відповідей. Сервер може зберігати IP-адреси і заголовки запитів останніх клієнтів. Проте сам протокол не обізнаний про попередні запити і відповідях, в ньому не передбачена внутрішня підтримка стану, до нього не пред'являються такі вимоги.


          Переваги

          Простота

          Протокол настільки простий у реалізації, що дозволяє з легкістю створювати клієнтські програми.

          Розширюваність

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

          Поширеність

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


          Недоліки і проблеми

          Великий розмір повідомлень

          Використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для вирішення даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, які дозволяють отримати клієнту документ з найбільш близького до нього сервера. Також до протоколу було впроваджене diff-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.


          Відсутність "навігації"

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

          Наприклад, з боку клієнта використовуються веб-павуки - спеціальні програми, які складають список ресурсів сервера, проходячи по всіх знайдених гіперпосиланнями. З боку сервера дана проблема вирішується за допомогою карти сайту ( англ. site map ) - Спеціальної веб-сторінки, де перераховані всі доступні для відвідин ресурси. Вона призначена не тільки для людей, граючи аналогічну змісту в книзі роль, а й корисна для тих же роботів-павуків, оскільки позволет зменшити глибину - мінімальну необхідну кількість переходів з головної сторінки. Для тих же цілей служать файли формату Sitemap, які призначені вже безпосередньо для роботів.

          Повністю ця проблема вирішена в розширювальному HTTP протоколі WebDAV за допомогою доданого методу PROPFIND. Даний метод дозволяє не тільки отримати дерево каталогів, а й список параметрів кожного ресурсу.


          Немає підтримки розподіленості

          Протокол HTTP розроблявся для рішення типових побутових задач, де саме по собі час обробки запиту має займати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. В 1998 W3C запропонував альтернативний протокол HTTP-NG ( англ. HTTP Next Generation ) Для повної заміни застарілого з акцентуванням уваги саме на цій області [2]. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває на стадії розробки.


          Програмне забезпечення

          Все програмне забезпечення для роботи з протоколом HTTP поділяється на три великі категорії:

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

          Для відмінності кінцевих серверів від проксі в офіційній документації використовується термін origin server (укр. вихідний сервер). Зрозуміло, один і той же програмний продукт може одночасно виконувати функції клієнта, сервера або посередника в залежності від поставлених завдань. У специфікаціях протоколу HTTP докладно описується поведінка для кожної з цих ролей.


          Клієнти

          Спочатку протокол HTTP розроблявся для доступу до гіпертекстових документів Всесвітньої павутини. Тому основними реалізаціями клієнтів є браузери (агенти користувача). Популярні браузери (в алфавітному порядку): Epiphany, Google Chrome, Internet Explorer, Konqueror, Mozilla Firefox, Opera, Safari.

          См також: Список браузерів і Порівняння браузерів

          Для перегляду збереженого вмісту сайтів на комп'ютері без з'єднання з Інтернетом були придумані офлайн-браузери. Серед відомих HTTrack і Offline Explorer.

          При нестабільному з'єднанні для завантаження великих файлів використовуються менеджери закачувань. Вони дозволяють у будь-який час докачати зазначені файли після втрати з'єднання з веб-сервером. В ОС Windows популярні програми Download Master, FlashGet, Free Download Manager, GetRight, ReGet. В Linux - графічний менеджер закачувань KGet і d4x (Downloader For X). Багато користувачів Linux воліють використання Wget - програми для завантаження файлів, яка сама по собі не є менеджером завантажень.

          Віртуальні атласи, такі як Google Планета Земля і NASA World Wind, теж використовують HTTP.

          Нерідко протокол HTTP використовується програмами для завантажування оновлення.

          Цілий комплекс програм-роботів використовується в пошукових системах Інтернету. Серед них веб-павуки (краулери), які виробляють прохід за гіперпосиланнями, складають базу даних ресурсів серверів і зберігають їх вміст для подальшого аналізу.


          Вихідні сервери

          Основні реалізації: Apache, Internet Information Services (IIS), lighttpd, nginx.

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

          Основні реалізації: Squid, UserGate, Multiproxy, Naviscope, Nginx.

          Історія розвитку

          HTTP/0.9

          HTTP був запропонований в березні 1991 Тімом Бернерсом-Лі, що працювали тоді в CERN, як механізм для доступу до документів в Інтернеті і полегшення навігації за допомогою використання гіпертексту. Найбільш рання версія протоколу HTTP/0.9 була вперше опублікована в січні 1992 р. (Хоча реалізація датується 1990 роком). Специфікація протоколу привела до впорядкування правил взаємодії між клієнтами і серверами HTTP, а також чіткому розподілу функцій між цими двома компонентами. Були задокументовані основні синтаксичні та семантичні положення.


          HTTP/1.0

          У травні 1996 для практичної реалізації HTTP був випущений інформаційний документ RFC 1945, що послужило основою для реалізації більшості компонентів HTTP/1.0.

          HTTP/1.1

          Поточна версія протоколу, прийнята в червні 1999 [прим 1]. Новим у цій версії був режим "постійного з'єднання": TCP -з'єднання може залишатися відкритим після відправки відповіді на запит, що дозволяє посилати кілька запитів за одне з'єднання. Клієнт тепер зобов'язаний надсилати інформацію про ім'я хоста, до якого він звертається, що уможливило більш просту організацію віртуального хостингу.

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

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

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

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


          Стартова рядок

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

          GET URI - для версії протоколу 0.9.
          Метод URI HTTP / Версія - для інших версій.

          Тут:

          • Метод ( англ. Method ) - Назва запиту, одне слово великими літерами. У версії HTTP 0.9 використовувався тільки метод GET, список запитів для версії 1.1 представлений нижче.
          • URI визначає шлях до запитуваного документа.
          • Версія ( англ. Version ) - Пара розділених крапкою арабських цифр. Наприклад: 1.0.

          Щоб запросити сторінку даної статті, клієнт повинен передати рядок:

          GET / wiki / HTTP HTTP/1.0

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

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

          Тут:

          • Версія - пара розділених крапкою арабських цифр як у запиті.
          • КодСостоянія ( англ. Status Code ) - Три арабські цифри. За кодом статусу визначається подальший вміст повідомлення і поведінку клієнта.
          • Пояснення ( англ. Reason Phrase ) - Текстове коротке пояснення до коду відповіді для користувача. Ніяк не впливає на повідомлення і є необов'язковим.

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

          HTTP/1.0 200 OK

          Методи

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

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

          Крім методів GET і HEAD, часто застосовується метод POST.


          OPTIONS

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

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

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

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


          GET

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

          Клієнт може передавати параметри виконання запиту в URI цільового ресурсу після символу "?":
          GET /path/resource?param1=value1¶m2=value2 HTTP/1.1

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

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


          HEAD

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

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

          POST

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

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

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

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


          PUT

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

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

          Повідомлення відповідей сервера на метод PUT не кешируєт.


          PATCH

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

          DELETE

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

          TRACE

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

          LINK

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

          UNLINK

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

          CONNECT

          Перетворює з'єднання запиту в прозорий TCP / IP тунель, зазвичай щоб сприяти встановленню захищеного SSL з'єднання через не шифрований проксі.

          Коди стану

          Код стану є частиною першого рядка відповіді сервера. Він являє собою ціле число з трьох арабських цифр [4]. Перша цифра вказує на клас стану. За кодом відповіді звичайно треба відокремлена пропуском пояснює фраза англійською мовою, яка роз'яснює людині причину саме такої відповіді. Приклади:

           201 Webpage Created 403 Access allowed only for registered users 507 Insufficient Storage 

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

          В даний час виділено п'ять класів кодів стану.

          1xx Informational ( рус. Інформаційний )
          У цей клас виділені коди, що інформують про процес передачі. В HTTP/1.0 повідомлення з такими кодами повинні ігноруватися. В HTTP/1.1 клієнт повинен бути готовий прийняти цей клас повідомлень як звичайна відповідь, але нічого відправляти серверу не потрібно. Самі повідомлення від сервера містять тільки стартову рядок відповіді і, якщо потрібно, декілька специфічних для відповіді полів заголовка. Проксі-сервери подібні повідомлення повинні відправляти далі від сервера до клієнта.
          2xx Success ( рус. Успіх )
          Повідомлення даного класу інформують про випадки успішного приймання та обробки запиту клієнта. Залежно від статусу сервер може ще передати заголовки і тіло повідомлення.
          3xx Redirection ( рус. Перенаправлення )
          Коди класу 3xx повідомляють клієнтові що для успішного виконання операції необхідно зробити інший запит (як правило по іншому URI). З даного класу п'ять кодів 301, 302, 303, 305 і 307 відносяться безпосередньо до перенапрямкам ( жарги. редирект). Адреса, за якою клієнту слід зробити запит, сервер указує в заголовку Location. При цьому допускається використання фрагментів в цільовому URI.
          4xx Client Error ( рус. Помилка клієнта )
          Клас кодів 4xx призначений для вказівки помилок з боку клієнта. При використанні всіх методів, крім HEAD, сервер повинен повернути в тілі повідомлення гіпертекстове пояснення для користувача.
          Для запам'ятовування значень кодів з 400 по 417 існують прийоми ілюстративної мнемотехніки [5]
          5xx Server Error ( рус. Помилка сервера )
          Коди 5xx виділені під випадки невдалого виконання операції з вини сервера. Для всіх ситуацій, крім використання методу HEAD, сервер повинен включати в тіло повідомлення пояснення, яке клієнт відобразить користувачеві.

          Заголовки

          Заголовки HTTP ( англ. HTTP Headers ) - Це рядки в HTTP-повідомленні, що містять розділену двокрапкою пару параметр-значення. Формат заголовків відповідає загальному формату заголовків текстових мережевих повідомлень ARPA (див. RFC 822). Заголовки повинні відділятися від тіла повідомлення хоча б одним порожнім рядком.

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

           Server: Apache/2.2.11 (Win32) PHP/5.3.0 Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT Content-Type: text / plain; charset = windows-1251 Content-Language: ru 

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

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

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

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

          Всі необхідні для функціонування HTTP заголовки описані в основних RFC, посилання на які є в кінці цієї статті. При цьому якщо вам не вистачатиме існуючих, то можете сміливо вводити свої. Традиційно до імен таких додаткових заголовків додають префікс "X-" для уникнення конфлікту імен з можливо існуючими. Наприклад, як у заголовках X-Powered-By або X-Cache. Деякі розробники використовують свої індивідуальні префікси. Прикладами таких заголовків можуть служити Ms-Echo-Request і Ms-Echo-Reply, введені корпорацією Microsoft для розширення WebDAV.


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

          Тіло 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 НЕ ПОВИННІ включати тіло повідомлення (message-body), навіть якщо присутні поля заголовка об'єкта (entity-header), які змушують повірити в присутність об'єкта. Ніякі відповіді з кодами стану 1xx (Інформаційні), 204 (Немає вмісту, No Content), і 304 (Не модифікований, Not Modified) НЕ ПОВИННІ містити тіла повідомлення (message-body). Всі інші відповіді містять тіло повідомлення, навіть якщо воно має нульову довжину.


          Приклади діалогів HTTP

          Звичайний GET-запит

          Запит клієнта:

           GET / wiki / сторінка HTTP/1.1 Host: ru.wikipedia.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text / html Connection : close (порожній рядок) 

          Відповідь сервера:

           HTTP/1.1 200 OK Date: Wed, 11 Feb 2009 11:20:59 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT Content -Language: ru Content-Type: text / html; charset = utf-8 Content-Length: 1234 Connection: close (далі йде запитана сторінка в  HTML) 

          Аналогічно виглядає відповідь 203. Що суттєво, безпосередньо запитувані дані відокремлені від HTTP-заголовків за допомогою CRLF CRLF (двох перекладів рядка).


          Перенаправлення

          Припустимо, що у вигаданій компанії Example Corp. є основний сайт за адресою http://example.com і домен-псевдонім example.org. Клієнт надсилає запит сторінки "Про компанію" на вторинний домен (частина заголовків опущена):

           GET / about.html HTTP/1.1 Host: example.org User-Agent: MyLonelyBrowser/5.0 

          Так як домен example.org не є основним і компанія не збирається в майбутньому його використовувати в інших цілях, їх сервер поверне код для постійного перенаправлення, вказавши в заголовку Location цільової URI :

           HTTP/1.x  301 Moved Permanently Location: http://example.com/about.html # contacts Date: Thu, 19 Feb 2009 11:08:01 GMT Server: Apache/2.2.4 Content-Type: text / html; charset = windows- 1251 Content-Length: 110  (Порожній рядок)     Click here    

          У заголовку Location можна вказувати фрагменти як в даному прикладі. Браузер не вказав фрагмент в запиті, так як його цікавить весь документ. Але він автоматично прокрутить сторінку до фрагмента "contacts", як тільки завантажить її. У тіло відповіді також був поміщений коротенький HTML-документ з посиланням, за допомогою якої відвідувач потрапить на цільову сторінку, якщо браузер не перейде на неї автоматично. Заголовок Content-Type містить характеристики саме цього HTML-пояснення, а не документа, який знаходиться за цільовим URL.

          Припустимо, ця ж компанія Example Corp. має кілька регіональних представництв по всьому світу. І для кожного представництва у них є сайт з відповідним ccTLD. Запит головної сторінки основного сайту example.com може виглядати так:

           GET / HTTP/1.1 Host: example.com User-Agent: MyLonelyBrowser/5.0 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9 ,*/*; q = 0.8 Accept-Language: ru, en-us; q = 0.7, en; q = 0.3 Accept-Charset: windows-1251, utf-8; q = 0.7, *; q = 0.7 

          Сервер прийняв до уваги заголовок Accept-Language і сформував відповідь з тимчасовим перенаправленням на російський сервер example.ru, вказавши його адресу в заголовку Location:

           HTTP/1.x  302 Found Location: http://example.ru/ Cache-Control: private Date: Thu, 19 Feb 2009 11:08:01 GMT Server: Apache/2.2.6 Content-Type: text / html; charset = windows-1251 Content-Length: 82  (Порожній рядок)     Example Corp. Росія    

          Зверніть увагу на заголовок Cache-Control. Значення "private" повідомляє іншим серверам (в першу чергу проксі) що відповідь може кешуватися на стороні клієнта. В іншому разі не виключено, що наступні відвідувачі з інших країн будуть переходити все ще не в своє представництво.

          Для перенаправлення також використовуються коди відповіді 303 (See Other) і 307 (Temporary Redirect).


          Докачка і фрагментарне скачування

          Припустимо, вигадана організація пропонує завантажити з сайту відео минулій конференції за адресою http://example.org/conf-2009.avi об'ємом приблизно 160 МБ. Розглянемо, як відбувається довантаження цього файлу в разі збою і як менеджер закачувань організував би багатопотокове завантаження декількох фрагментів.

          В обох випадках клієнти зроблять свій перший запит на зразок цього:

           GET / conf-2009.avi HTTP/1.0 Host: example.org Accept: * / * User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Referer: http://example.org/ 

          Тема Referer вказує, що файл був запитаний з головної сторінки сайту. Менеджери закачувань зазвичай теж його вказують, щоб емулювати перехід зі сторінки сайту. Без нього сервер може відповісти 403 (Access Forbidden), якщо не допускаються запити з інших сайтів. У нашому випадку сервер повернув успішну відповідь:

           HTTP/1.1 200 OK Date: Thu, 19 Feb 2009 12:27:04 GMT Server: Apache/2.2.3 Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Content-Type: video / x-msvideo Content-Length: 160993792 Accept-Ranges: bytes Connection: close  (Порожній рядок)  (Двійкове вміст всього файлу) 

          Заголовок Accept-Ranges інформує клієнта про те, що він може запитувати у сервера фрагменти, вказуючи їх зміщення від початку файлу в байтах. Якщо цей заголовок відсутній, то клієнт може попередити користувача, що докачати файл, швидше за все, не вдасться. Виходячи із значення заголовка Content-Length, менеджер закачувань поділить весь обсяг на рівні фрагменти і запросить їх окремо, організувавши кілька потоків. Якщо сервер не вкаже розмір, то клієнту паралельне скачування реалізувати не вдасться, але при цьому він зможе докачувати файл, поки сервер не відповість 416 (Requested Range Not Satisfiable).

          Припустимо, на 84-му мегабайті з'єднання з Інтернетом перервалося і процес завантаження призупинився. Коли з'єднання з Інтернетом було відновлено, менеджер закачувань автоматично послав новий запит на сервер, але із зазначенням видати вміст з вісімдесят четвертого мегабайта:

           GET / conf-2009.avi HTTP/1.0 Host: example.org Accept: * / * User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Range: bytes = 88080384 - Referer: http://example. org / 

          Сервер не зобов'язаний пам'ятати, які і від кого запити були до цього, і тому клієнт знову вставив заголовок Referer, як ніби це його найперший запит. Вказане значення заголовка Range говорить серверу - "видай вміст від 88080384-ого байта до самого кінця". У зв'язку з цим сервер поверне відповідь:

           HTTP/1.1  206 Partial Content Date: Thu, 19 Feb 2009 12:27:08 GMT Server: Apache/2.2.3 Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Accept-Ranges : bytes Content-Range: bytes 88080384-160993791/160993792 Content-Length: 72913408 Connection: close Content-Type: video / x-msvideo  (Порожній рядок)  (Двійкове вміст від вісімдесят четвертого мегабайта) 

          Заголовок Accept-Ranges тут вже не обов'язковий, тому що клієнт уже знає про цю можливості сервера. Про те, що передається фрагмент, клієнт дізнається за кодом 206 (Partial Content). У заголовку Content-Range міститься інформація про даний фрагменті: номери початкового і кінцевого байта, а після слеша - сумарний обсяг усього файлу в байтах. Зверніть увагу на заголовок Content-Length - у ньому вказується розмір тіла повідомлення, тобто переданого фрагмента. Якщо сервер поверне кілька фрагментів, то Content-Length буде утримувати їх сумарний об'єм.

          Тепер повернемося до менеджера завантажень. Знаючи сумарний обсяг файлу "conf-2009.avi", програма поділила його на 10 рівних секцій. Початкову менеджер завантажить при самому першому запиті, перервавши з'єднання як тільки дійде до початку другого. Решта він запросить окремо. Наприклад, 4-а секція буде запитана з наступними заголовками (частина заголовків опущена - див повний приклад вище):

           GET / conf-2009.avi HTTP/1.0 Range: bytes = 64397516-80496894 

          Відповідь сервера в цьому випадку буде наступним (частина заголовків опущена - див повний приклад вище):

           HTTP/1.1  206 Partial Content Accept-Ranges: bytes Content-Range: bytes 64397516-80496894/160993792 Content-Length: 16099379  (Порожній рядок)  (Двійкове вміст 4-ої частини) 

          Якщо подібний запит надіслати серверу, який не підтримує фрагменти, то він поверне стандартну відповідь 200 (OK) як було показано на самому початку, але без заголовка Accept-Ranges.


          Основні механізми протоколу

          Часткові GET

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

          Для отримання фрагмента клієнт посилає серверу запит з заголовком Range, вказуючи в ньому необхідні байтові діапазони. Якщо сервер не розуміє часткові запити (ігнорує заголовок Range), то він поверне все вміст зі статусом 200, як і при звичайному GET. У разі успішного виконання сервер повертає замість коду 200 відповідь зі статусом 206 (Partial Content), включаючи у відповідь заголовок Content-Range. Самі фрагменти можуть бути передані двома способами:

          • У відповіді міститься заголовок Content-Range із зазначенням байтових діапазонів. Відповідно до них фрагменти послідовно поміщаються в основне тіло. При цьому Content-Length повинен відповідати сумарним обсягом всього тіла.
          • Сервер вказує медіа тип multipart / byteranges для основного вмісту і передає фрагменти вказуючи відповідний Content-Range для кожного елемента).

          Умовні GET

          Метод GET змінюється на "умовний GET", якщо повідомлення запиту містить у собі поле заголовка "If-Modified-Since". У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, зазначеної в заголовку "If-Modified-Since". Алгоритм визначення цього містить у собі наступні випадки:

          • Якщо код статусу відповіді на запит буде відрізнятися від "200 OK", або дата, зазначена в полі заголовка "If-Modified-Since" некоректна, відповідь буде ідентична відповіді на звичайний запит GET.
          • Якщо після зазначеної дати ресурс змінювався, відповідь буде також ідентична відповіді на звичайний запит GET.
          • Якщо ресурс не змінювався після зазначеної дати, сервер поверне код статусу "304 Not Modified".

          Використання методу умовний GET спрямовано на розвантаження мережі, тому що він дозволяє не передавати по мережі надлишкову інформацію.


          Узгодження вмісту

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

          Розрізняють два основних типи узгоджень:

          • Кероване сервером ( англ. Server-Driven ).
          • Кероване клієнтом ( англ. Agent-Driven ).

          Одночасно можуть бути використані обидва типи або кожен з них окремо.

          В основній специфікації по протоколу (RFC два тисячі шістсот шістнадцять) також виділяється так зване прозоре узгодження ( англ. Transparent Negotiation ) Як кращий варіант комбінування обох типів. Останній механізм не слід плутати з незалежною технологією Transparent Content Negotiation (TCN, рус. Прозоре узгодження вмісту , См. RFC 2295), яка не є частиною протоколу HTTP, але може використовуватися з ним. В обох істотна відмінність в принципі роботи та самому значенні слова "прозоре" (transparent). У специфікації по HTTP під прозорістю мається на увазі, що процес не помітний для клієнта і сервера, а в технології TCN прозорість означає доступність повного списку варіантів ресурсу для всіх учасників процесу доставки даних.


          Кероване сервером

          При наявності декількох версій ресурсу сервер може аналізувати заголовки запиту клієнта, щоб видати, на його думку, найбільш підходящу. В основному аналізуються заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages ​​і User-Agent. Сервера бажано включати у відповідь заголовок Vary із зазначенням параметрів, за якими відрізняється вміст по запитуваній URI.

          Географічне положення клієнта можна визначити по віддаленому IP-адресою. Це можливо за рахунок того що IP-адреси, як і доменні імена, реєструються на конкретну людину або організацію. При реєстрації вказується регіон, в якому буде використовуватися бажане адресний простір. Ці дані загальнодоступні, і в Інтернеті можна знайти відповідні вільно поширювані бази даних і готові програмні модулі для роботи з ними (слід орієнтуватися на ключові слова "Geo IP"). Слід пам'ятати що такий метод здатний визначити місце розташування максимум з точністю до міста (звідси визначається і країна). При цьому інформація актуальна тільки на момент реєстрації адресного простору. Тобто, наприклад, якщо московський провайдер зареєструє діапазон адрес з вказівкою Москви і почне надавати доступ клієнтам з найближчого Підмосков'я, то його абоненти можуть на деяких сайтах спостерігати що вони з Москви, а не з, приміром, Красногорська або Дзержинського.

          Кероване сервером узгодження має декілька недоліків:

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

          Кероване клієнтом

          В даному випадку тип вмісту визначається тільки на стороні клієнта. Для цього сервер повертає з кодом стану 300 (Multiple Choices) або 406 (Not Acceptable) список варіантів, серед яких користувач вибирає відповідний. Кероване клієнтом узгодження добре, коли вміст різниться за найчастішим параметрами (наприклад, за мовою та кодуванні) і використовується публічний кеш. Основний недолік - зайве навантаження, тому що доводиться робити додатковий запит, щоб отримати потрібний вміст.


          Прозоре узгодження

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

          В основній специфікації по протоколу HTTP механізм прозорого узгодження докладно не описаний.

          Множинне вміст

          Протокол HTTP підтримує передачу кількох сутностей в межах одного повідомлення. Причому сутності можуть передаватися не тільки у вигляді однорівневої послідовності, але у вигляді ієрархії з вкладенням елементів один в одного. Для позначення множини вмісту використовуються медіатіпи multipart / *. Робота з такими типами здійснюється за загальними правилами, описаним в RFC 2046 (якщо інше не визначено конкретних медіа типом). Якщо одержувачу не відомо як працювати з типом, то він обробляє його так само, як multipart / mixed. Параметр boundary означає роздільник між різними типами передаються. Наприклад передається з форми параметр DestAddress передає значення e-mail адреси, а последущей за ним елемент AttachedFile1 відправляє двійкове вміст зображення формату. Jpg З боку сервера повідомлення з множинним вмістом можуть надсилатися у відповідь на часткові GET при запиті декількох фрагментів ресурсу. У цьому випадку використовується медіа тип multipart / byteranges.

          З боку клієнта при відправці HTML -форми найчастіше користуються методом POST. Типовий приклад: сторінки відправки електронних листів з вкладеними файлами. При відправці такого листа браузер формує повідомлення типу multipart / form-data, інтегруючи в нього як окремі частини, введені користувачем, тему листа, адреса одержувача, сам текст і вкладені файли:

           POST / send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form- data; boundary = "Asrf456BGe4h" Content-Length:  (Сумарний обсяг, включаючи дочірні заголовки)  Connection: keep-alive Keep-Alive: 300  (Порожній рядок)  (Відсутня преамбула)  - Asrf456BGe4h Content-Disposition: form-data; name = "DestAddress"  (Порожній рядок)  brutal-vasya@example.com - Asrf456BGe4h Content-Disposition: form-data; name = "MessageTitle"  (Порожній рядок)  Я гніваюся - Asrf456BGe4h Content-Disposition: form-data; name = "MessageText"  (Порожній рядок)  Привіт, Василь! Твій ручної лев, якого ти залишив у мене минулого тижня, роздер весь мій диван. Будь ласка, забери його швидше! У вкладенні дві фотки з наслідками. - Asrf456BGe4h Content-Disposition: form-data; name = "AttachedFile1"; filename = "horror-photo-1.jpg" Content-Type: image / jpeg  (Порожній рядок)  (Двійкове вміст першій фотографії)  - Asrf456BGe4h Content-Disposition: form-data; name = "AttachedFile2"; filename = "horror-photo-2.jpg" Content-Type: image / jpeg  (Порожній рядок)  (Двійкове вміст другої фотографії)  - Asrf456BGe4h -  (Відсутній епілог) 

          У прикладі в заголовках Content-Disposition параметр name відповідає атрибуту name в HTML-тегах і


          Цей текст може містити помилки.

          Схожі роботи | скачати

          Схожі роботи:
          HTTP cookie
          HTTP referer
          Список заголовків HTTP
          Список кодів стану HTTP
© Усі права захищені
написати до нас
Рейтинг@Mail.ru