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

Погляньмо на цей протокол через призму нашої професії. У першій частині пройдемося основами, подивимося на запити/відповіді. У наступній статті розберемо більш детальні фішки, такі як кешування, обробка підключення та автентифікація.

Також у цій статті я буду в основному посилатися на стандарт RFC 2616: Hypertext Transfer Protocol - HTTP/1.1.

Основи HTTP

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

В основному для спілкування використовується TCP/IP, але це не єдиний можливий варіант. За замовчуванням TCP/IP використовує порт 80, але можна заюзати й інші.

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

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

URL

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

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

Методи

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

Існуючі методи:

GET: отримати доступ до наявного ресурсу В URL перерахована вся необхідна інформація, щоб сервер зміг знайти і повернути як відповідь шуканий ресурс.

POST: використовується для створення нового ресурсу POST запит зазвичай містить у собі всю потрібну інформаціюстворення нового ресурсу.

PUT: оновити поточний ресурс. PUT запит містить оновлювані дані.

DELETE: Видалення існуючого ресурсу.

Дані методи найпопулярніші і найчастіше використовуються різними інструментами та фреймворками. У деяких випадках, PUT та DELETE запити надсилаються за допомогою відправки POST, у змісті якого зазначено дію, яку потрібно вчинити з ресурсом: створити, оновити чи видалити.

Також HTTP підтримує інші методи:

HEAD: аналогічний GET. Різниця в тому, що при цьому виді запиту не передається повідомлення. Сервер отримує лише заголовки. Використовується, наприклад, щоб визначити, чи було змінено ресурс.

TRACE: під час передачі запит проходить через безліч точок доступу та проксі серверів, кожен із яких вносить свою інформацію: IP, DNS. За допомогою даного методу можна побачити всю проміжну інформацію.

OPTIONS: використовується для визначення можливостей сервера, його параметрів та конфігурації для конкретного ресурсу.

Коди стану

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

1xx: Інформаційні повідомлення

Набір цих кодів було введено у HTTP/1.1. Сервер може надіслати запит виду: Expect: 100-continue, що означає, що клієнт ще відправляє частину запиту. Клієнти, що працюють з HTTP/1.0, ігнорують дані заголовки.

2xx: Повідомлення про успіх

Якщо клієнт отримав код із серії 2xx, то запит пішов успішно. Найпоширеніший варіант – це 200 OK. При запиті GET, сервер відправляє відповідь в тілі повідомлення. Також існують інші можливі відповіді:

• 202 Accepted: запит прийнятий, але може містити ресурс у відповіді. Це корисно для асинхронних запитівна стороні сервера. Сервер визначає, надіслати ресурс чи ні.
• 204 No Content: у тілі відповіді немає повідомлення.
• 205 Reset Content: вказівка ​​серверу про скидання представлення документа
• 206 Partial Content: відповідь містить лише частину контенту. У додаткових заголовках визначається загальна довжина контенту та інфа.

3xx: Перенаправлення

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

• 301 Moved Permanently: ресурс тепер можна знайти інакше URL адресою.
• 303 See Other: ресурс тимчасово можна знайти за іншою URL-адресою. Заголовок Location містить тимчасову URL-адресу.
• 304 Відмінно: сервер визначає, що ресурс не змінено і клієнту потрібно задіяти закешированную версію відповіді. Для перевірки ідентичності інформації використовується ETag (хеш Сутності – Enttity Tag);

4xx: Клієнтські помилки

Цей клас повідомлень використовується сервером, якщо він вирішив, що запит було надіслано з помилкою. Найбільш поширений код: 404 Not Found. Це означає, що ресурс не знайдено на сервері. Інші можливі коди:

• 400 Bad Request : питання було сформовано невірно
• 401 Unauthorized: для запиту потрібна аутентифікація. Інформація передається через заголовок Authorization.
• 403 Forbidden: сервер не відкрив доступ до ресурсу
• 405 Method Not Allowed: неправильний метод HTTP був задіяний для того, щоб отримати доступ до ресурсу.
• 409 Conflict: сервер неспроможна остаточно обробити запит, т.к. намагається змінити більше нову версіюресурсу. Це часто відбувається при запитах PUT.

5xx: Помилки сервера

Ряд кодів, що використовуються визначення помилки сервера під час обробки запиту. Найпоширеніший: 500 Internal Server Error. Інші варіанти:

• 501 Not Implemented: сервер не підтримує потрібну функціональність.
• 503 Service Unavailable: це може статися, якщо на сервері сталася помилка або він перевантажений. Зазвичай у разі, сервер не відповідає, а час, дане відповідь, минає.

Формати повідомлень запиту/відповіді

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

Давайте подивимося на структуру повідомлення, що передається через HTTP:

Message = *() CRLF [ ] = Request-Line | Status-Line = Field-Name ":" Field-Value

Між заголовком і тілом повідомлення повинен обов'язково бути порожній рядок. Заголовків може бути декілька:

Тіло відповіді може містити повну інформаціюабо її частина, якщо активовано відповідну можливість (Transfer-Encoding: chunked). HTTP/1.1 також підтримує заголовок Transfer-Encoding.

Загальні заголовки

Ось кілька видів заголовків, які використовуються як у запитах, так і у відповідях:

General-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

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

Заголовок via використовується у запиті типу TRACE, та оновлюється всіма проксі-серверами.

Заголовок Pragma використовується для перерахування власних заголовків. Наприклад, Pragma: no-cache - це те саме, що Cache-Control: no-cache. Докладніше про це поговоримо у другій частині.

Заголовок Date використовується для зберігання дати та часу запиту/відповіді.

Заголовок Upgrade використовується для зміни протоколу.

Transfer-Encoding призначається поділу відповіді кілька фрагментів з допомогою Transfer-Encoding: chunked. Це новація версії HTTP/1.1.

Заголовки сутностей

У заголовках сутностей передається мета-інформація контенту:

Entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified

Всі заголовки з префіксом Content-надають інформацію про структуру, кодування та розмір тіла повідомлення.

Заголовок Expires містить час і дату закінчення сутності. Значення “never expires” означає час + 1 код з поточного моменту. Last-Modified містить час і дату останньої змінисутності.

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

Формат запиту

Запит виглядає приблизно так:

Request-Line = Метод SP URI SP HTTP-Version CRLF Метод = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "DELETE" | "TRACE"

SP – це роздільник між токенами. Версія HTTP вказується у HTTP-Version. Реальний запит має такий вигляд:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml; q=0.9,*/*;q=0.8

Список можливих заголовків запиту:

Request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | від | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent

У заголовку Accept визначається підтримувані mime типи, мова, кодування символів. Заголовки From, Host, Referer та User-Agent містять інформацію про клієнта. Префікси If призначені для створення умов. Якщо умова не пройшла, виникне помилка 304 Not Modified.

Формат відповіді

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

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP версія
• Код статусу
• Повідомлення статусу, зрозуміле для людини

Звичайний статус виглядає приблизно так:

HTTP/1.1 200 OK

Заголовки відповіді можуть бути такими:

Response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

• Age час у секундах, коли повідомлення було створено на сервері.
• ETag MD5 сутності для перевірки змін та модифікацій відповіді.
• Location використовується для перенаправлення та містить нову URL-адресу.
• Server визначає сервер, де було сформовано відповідь.

Думаю, на сьогодні теорії достатньо. Тепер давайте поглянемо на інструменти, якими ми можемо скористатися для моніторингу HTTP повідомлень.

Інструменти для визначення HTTP трафіку

Існує безліч інструментів для моніторингу HTTP трафіку. Ось кілька із них:

Найчастіше використовується - це Chrome Developers Tools:

Якщо говорити про відладчика, можна скористатися Fiddler:

Для відстеження HTTP трафіку вам знадобиться curl, tcpdump та tshark.

Бібліотеки для роботи з HTTP - jQuery AJAX

Оскільки jQuery дуже популярний, він також має інструментарій для обробки HTTP відповідей при AJAX запитах. Інформацію про jQuery.ajax(settings) можна знайти на офіційному сайті.

Передаючи об'єкт налаштувань (settings), а також скориставшись функцією зворотного виклику beforeSend, ми можемо задати заголовки запиту за допомогою методу setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", тип: "GET", beforeSend: function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); )));

Якщо хочете обробити статус запиту, це можна зробити так:

$.ajax(( statusCode: ( 404: function() ( alert("page not found"); ) )));

Підсумок

Ось такий він, тур по основах протоколу HTTP. У другій частині буде ще більше цікавих фактів та прикладів.

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

Переваги

Простота

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

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

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

Поширеність

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

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

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

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

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

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

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

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

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

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

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

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

Клієнти

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

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

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

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

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

Також: Список пошукових машин , Архів Інтернету

Сервери походження

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

Також: Список веб-серверів

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

Основні реалізації: UserGate, Multiproxy, Naviscope, Список веб-серверів

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

HTTP/0.9

HTTP/1.0

HTTP/1.1

Поточна версія протоколу прийнята в червні року. Новим у цій версії був режим «постійного з'єднання»: Starting line) - визначає тип повідомлення;

Заголовки (англ. Headers) - характеризують тіло повідомлення, параметри передачі та інші відомості;

Тіло повідомлення (англ. Message Body) - безпосередньо дані повідомлення. Обов'язково має відокремлюватися від заголовків порожнім рядком.

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

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

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

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

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

GET /wiki/Http HTTP/1.0

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

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

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

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

HTTP/1.0 200 Ok

Методи

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

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

HEAD

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

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

POST

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

На відміну від методу GET, метод POST не вважається ідемпотентним, тобто багаторазове повторення тих самих запитів 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

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

CONNECT

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

LINK

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

UNLINK

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

Коди стану

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

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

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

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

Заголовки

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

Приклади діалогів 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.0 200 OK Дата: 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 -Language: uk Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close (далі слідує запитана сторінка в

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

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

Location: http://www.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 може виглядати так:

/ HTTP/1.1 Host: www.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://www.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" повідомляє іншим серверам (насамперед проксі) що відповідь може кешуватися за клієнта. В іншому випадку не виключено, що наступні відвідувачі з інших країн переходитимуть весь час не до свого представництва.

Для перенаправлення також використовуються коди відповіді (See Other) та (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 вказує, що файл було запрошено з головної сторінки сайту. Менеджери завантажень зазвичай теж вказують, щоб емулювати перехід зі сторінки сайту. Без цього сервер може відповісти (Acccess Forbidden), якщо не допускаються запити з інших сайтів. У нашому випадку сервер повернув успішну відповідь:

HTTP/1.1 200 OK Дата: 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-9989205 -Type: video/x-msvideo Content-Length: 160993792 Accept-Ranges: bytes Connection: close (порожня стрічка) (двійковий вміст всього файлу)

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

Припустимо, на 84-му мегабайті з'єднання з Інтернетом перервалося і процес завантаження припинився. Коли з'єднання з Інтернетом було відновлено, браузер автоматично надіслав новий запит на сервер, але із зазначенням видати вміст з 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Дата: 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 (порожня стрічка) (двійковий вміст від 84-го мегабайта)

Заголовок Accept-Ranges тут не обов'язковий, оскільки клієнт знає про цю можливість сервера. Про те, що передається фрагмент, клієнт дізнається за кодом (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-ої частини)

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

також байтові діапазони , відповідь 406 , відповідь 416 .

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

Часткові GET

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

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

Див. також .

Умовні GET

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

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

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

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

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

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

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

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

Географічне положення клієнта можна визначити за віддаленою IP-адресою.

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

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

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

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

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

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

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

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

Основна стаття: ієрархії із вкладенням елементів один одного. Для позначення множинного вмісту використовуються медіатипи multipart/*. Робота з такими типами здійснюється за загальними правилами, описаними в RFC 2046 (якщо інше не визначено конкретним типом медіа). Якщо одержувачу невідомо як працювати з типом, він обробляє його як і, як multipart/mixed .

З боку сервера повідомлення з множинним вмістом можуть надсилатися у відповідь на при запиті кількох фрагментів ресурсу. У цьому випадку використовується медіа тип multipart/byteranges.

Стандартний протоколдля передачі даних по Всесвітнього павутиння- це HTTP ( HyperText Transfer Protocol - протокол передачі гіпертексту). Він описує повідомлення, якими можуть обмінюватися клієнти та сервери. Кожна взаємодія складається з одного ASCII-запиту, на який слідує одна відповідь, що нагадує відповідь стандарту RFC 822 MIME. Усі клієнти та всі сервери повинні дотримуватися цього протоколу. Він визначений у RFC 2616.

З'єднання

Звичайний спосіб взаємодії браузера з сервером полягає у встановленні ТСР-з'єднання з портом 80 сервера, хоча формально ця процедура не є обов'язковою. Цінність використання TCP - у тому, що ні браузерам, ні серверам не доводиться турбуватися про втрачені, дубльовані, занадто довгі повідомлення та підтвердження. Усе це забезпечується протоколом TCP.

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

Це привело до створення протоколу HTTP 1.1, який підтримував стійкі з'єднання. Це означало, що з'явилася можливість встановлення TCP-з'єднання, надсилання запиту, отримання відповіді, а потім передачі та прийому додаткових запитів та відповідей. Таким чином, знизилися накладні витрати, що виникали при постійних установках та розривах з'єднання. Стало можливим також конвеєризувати запити, тобто надсилати запит 2 ще до відповіді на запит 1.

Незважаючи на те, що HTTP був розроблений спеціально для використання в веб-технологіях, він був навмисно зроблений більш універсальним, ніж це було необхідно, оскільки розраховувався на майбутнє застосування в об'єктно-орієнтованих додатках. З цієї причини на додаток до звичайних запитів веб-сторінок були розроблені спеціальні операції, які називаються методами. Вони завдячують своїм існуванням технології SOAP. Кожен запит складається з одного або декількох рядків ASCII, причому перше слово є ім'ям методу, що викликається. Вбудовані методи перераховані у таблиці на рис.6. Крім цих загальних методів, у різних об'єктівможуть бути свої специфічні методи. Імена методів чутливі до регістру символів, тобто метод GETіснує, a get - ні.

Малюнок 6 - Вбудовані методи HTTP-запитів

Метод GET запитує у сервера сторінку (під якою в загальному випадку мається на увазі об'єкт, але на практиці це просто файл), закодовану згідно стандарту MIME. Більшість запитів до сервера становлять саме запити GET.

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

Метод PUT є протилежністю методу GET: не читає, а записує сторінку. Це дозволяє створити набір веб-сторінок на віддаленому сервері. Тіло запиту містить сторінку. Вона може бути кодована за допомогою MIME. У цьому випадку рядки, що йдуть за командою PUT, можуть включати різні заголовки, наприклад Content-Type або заголовки автентифікації, що підтверджують права абонента на запитувану операцію.

Метод POST дещо нагадує метод PUT. Він також містить URL, але замість заміни наявних даних нові дані «додаються» (у певному загальному сенсі) до існуючих. Це може бути публікація повідомлення у конференції або додавання файлу до електронної дошки оголошень BBS. Насправді ні PUT, ні POST широко застосовуються.

Метод DELETE, що не дивно, видаляє сторінку. Як і в методі PUT, тут особливу рольможуть грати автентифікація та дозвіл на виконання цієї операції. Навіть за наявності у користувача дозволу на видалення сторінки немає жодної гарантії, що метод DELETE видаляє сторінку, оскільки навіть за згодою віддаленого HTTP-серверасам файл може бути захищеним від зміни чи переміщення.

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

Метод CONNECT зараз не використовується. Він зарезервований для майбутнього застосування.

Метод OPTIONS дозволяє клієнту дізнатися у сервера про його властивості чи властивості якогось конкретного файла.

У відповідь на кожен запит від сервера надходить відповідь, що містить рядок стану, а також можливо додаткову інформацію (наприклад, веб-сторінку або її частину). Рядок стану може містити трирозрядний код стану, що повідомляє про успішне виконання запиту або причини невдачі. Перший розряд призначений для поділу всіх відповідей п'ять основних груп, як у таблиці на рис.7. Коди, що починаються з 1 Aх), на практиці використовуються рідко. Коди, що починаються з 2, означають, що запит був успішно оброблений і дані (якщо їх запитували) надіслані. Коди Зхх повідомляють клієнту про те, що потрібно спробувати щастя в іншому місці - використовуючи інший URL, або свій власний кеш.

Рисунок 7 - Групи кодів стану, що містяться у відповідях сервера

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

Приклад використання HTTP

Оскільки HTTP є текстовим протоколом, Взаємодія з сервером за допомогою терміналу (який в даному випадку виступає як протилежність браузеру) можна організувати досить просто. Необхідно встановити TCP-з'єднання з портом 80 сервера. Читачеві надається можливість самому подивитися, як працює цей сценарій (краще запускати його в системі UNIX, оскільки деякі інші системи можуть не відображати статус з'єднання). Отже, послідовність команд така:

Малюнок 8 - послідовність команд HTTP-протоколу

Ця послідовність команд встановлює telnet-з'єднання (тобто ТСР- з'єднання) з портом 80 веб-сервера IETF, розташованого за адресою www.ietf.org.

Результат сеансу зв'язку записується у файл log, який потім можна переглянути. Далі йде команда GET. Вказується ім'я файлу і протокол передачі. Далі йде обов'язковий рядок із заголовком Host. Порожній рядок, який знаходиться за ним, також є обов'язковим. Вона сигналізує серверу у тому, що заголовки запитів закінчилися. Команда close (це команда програми telnet) з'єднання розривається.

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

Малюнок 9 - Початок виведення файлу "www.ietf.org/rfc.html"

Перші три рядки у цьому лістингу створено програмою telnet, а не віддаленим сайтом. А ось рядок, що починається з HTTP/1.1, - це вже відповідь IETF, що говорить про те, що сервер бажає спілкуватися з вами за допомогою протоколу НТТР/1.1. Далі слідує ряд заголовків і, нарешті, сам вміст файлу, що запитується. Заголовок ETag, який є унікальним ідентифікатором сторінки, пов'язаним з кешуванням, та X-Pad - нестандартного заголовка, що допомагає боротися з помилками браузерів.

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

Як і більшість троянських вірусів, Time to Read виконує просте завдання – показати користувачеві максимальна кількістьреклами, щоб творці програми отримали гроші за її трансляцію, кліки по ній та перекази на сайти-партери. Найчастіше послугами просування своїх сайтів за допомогою вірусів користуються шахрайські ресурси або сторінки, які заражені більш серйозним, ніж рекламний троян.

Вірус Time to Read після попадання на комп'ютер поводиться такими «симптомами»:

• На сайтах постійно спливає додаткова реклама, у тому числі й pop-up банери, які повністю загороджують контент до натискання на них;
• Налаштування безпеки комп'ютера змінюються, що небезпечно для комп'ютера, який має постійне підключеннядо Інтернету;
• Стартова сторінка всіх браузерів автоматично змінюється на сайт Time to Read, який прагне позиціонувати себе як пошук і ресурс новин;
• Автоматична переадресація на сторонні ресурси. Важливо: з невідомого сайту, який користувач може бути переадресований вірусом Time to Read, великий ризик завантаження на комп'ютер інших вірусів.

Якщо ви помітили на комп'ютері зазначені вище симптоми, ваш комп'ютер заражений вірусом Time to Read. Необхідно його терміново видалити, щоб уникнути більше серйозних проблем, до яких може привести.

Щоб прибрати вірус Time to Read з комп'ютера, потрібно завантажити та встановити дві програми: AdwCleaner і CCleaner. Дані програми допоможуть у автоматичному режимівпоратися з вірусом, і користувачеві залишиться виконати лише найпростіші завдання у «ручному» режимі.

Процес видалення вірусу Time to Read з комп'ютера проходить так:

1. Насамперед необхідно видалити з комп'ютера все тимчасові файли, щоб вірусна програма не могла відновитись після видалення. Для цього перейдіть до відповідних розділів:

На Windows 7:(Системний диск):\Users\Ім'я користувача\AppData\Local\Temp На Windows 10:(Системний диск):\Users\Адміністратор\AppData\Local\Temp

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

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

Як встановити та правильно налаштувати CCleaner:

На цьому видалення вірусу Time to Read з комп'ютера можна вважати завершеним. Рекомендуємо до початку роботи з браузером перезавантажити комп'ютер.

Найчастіше вірус Time to Read потрапляє на комп'ютер користувача через його необережність. Декілька базових рекомендацій, які допоможуть значно знизити ризик зараження комп'ютера цим трояном:

• Завантажуйте програми в Інтернеті лише з перевірених сайтів. Якщо програма розповсюджується вільно, краще завантажити її з сайту розробників;
• Під час встановлення програм слідкуйте уважно за всіма «галочками» в установнику. Часто під « повною установкоюпрограми» її розробники розуміють інсталяцію програми з партнерським софтом, який може бути вірусним. Також рекомендуємо знайомитися з користувальницькою угодою, у якому може бути зазначено, що за умовчанням на комп'ютер встановиться та чи інша програма партнерства;
• Не завантажуйте з Інтернету програми від невідомих розробників, які обіцяють неймовірну функціональність.

Дотримуючись простих правил, описаних вище, можна істотно знизити ризик зараження комп'ютера вірусом Time to Read, який здатний завдати маси клопоту.

Усі дані в рамках Web-технології передаються за протоколом HTTP(HyperText Transfer Protocol). Виняток становить обмін з використанням програмування Java або обмін з Plugin-пропозицій. Враховуючи реальний обсяг трафіку, який передається в рамках Web-обміну HTTP, ми розглядатимемо лише цей протокол. При цьому ми розглянемо такі питання, як:

Загальна структура повідомлень

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

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

Тіло повідомлення не обов'язкове на відміну від заголовка повідомлення. Вона може містити текст, графіку, аудіо- або відеоінформацію.

Нижче наведено HTTP-запит:

GET / HTTP/1.0 Accept: image/jpeg [порожня стрічка]

та відгук:

HTTP/1.0 200 OK Дата: Fri, 24 Jul 1998 21:30:51 GMT Server: Apache/1.2.5 Content-type: text/html Content-length: 21345 [порожня стрічка]контекст сторінки

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

Сервер, приймаючи запит від клієнта, частина інформації заголовка HTTP-запиту перетворює на змінні оточення, які доступні для аналізу CGI-скриптом Якщо запит має тіло, тіло стає доступним скрипту через потік стандартного введення.

Методи доступу

Найголовнішою директивою HTTP-запиту є метод доступу. Він вказується першим словом у першому рядку запиту. У прикладі це GET. Розрізняють чотири основні методи доступу:

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

Метод GET

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

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

Метод HEAD

Метод HEAD використовується для мінімізації обмінів під час роботи з протоколом HTTP. Він аналогічний методу GET крім того, що у відгуку не передається тіла повідомлення. Даний метод використовується для перевірки часу останньої модифікації ресурсу, перевірки терміну придатності кешованих ресурсів, при використанні програм сканування ресурсів World Wide Web. Одним словом, метод HEAD призначений для мінімізації обсягу інформації, що передається по мережі в рамках HTTP-обміну.

Метод POST

Метод POST – це альтернатива методу GET. При обміні даними за методом POST у запиті клієнта є тіло HTTP-повідомлення. Це тіло може формуватися з даних, що вводяться в HTML-формі, або з зовнішнього приєднаного файлу. У відгуку зазвичай є і заголовок і тіло HTTP-повідомлення. Для ініціювання обміну методом POST в атрибуті методконтейнера formслід зазначити значення "post".

Метод PUT

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

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

Оптимізація обміну

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

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

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

Для оптимізації числа відкритих TCP-з'єднань у протоколі HTTP версій 1.0 і 1.1 передбачений режим keep-alive. У цьому режимі з'єднання ініціалізується лише один раз і по ньому можна послідовно реалізувати кілька HTTP-обмінів.

Для реалізації підтримки сесій до директив HTTP-заголовка були додані "ключики" (Cookies). Вони дозволяють проімітувати підтримку з'єднання під час роботи за протоколом HTTP.

Кодування GET та POST-запитів.

Існують два види кодування HTTP-запиту. Основний - urlencoded, він - стандартне кодування URL. Пробіл представляється як %20, російські літери та більшість спецсимволів кодуються, англійські літери та дефіс залишаються як є.

Спосіб, яким слід кодувати дані форми при submit"е, задається в її HTML-тазі:

// метод GET із кодуванням за умовчанням // enctype явно задає кодування // метод POST з кодуванням за умовчанням (urlencoded, як і попередня форма)

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

Другий спосіб кодування - відсутність кодування. Наприклад, кодувати не потрібно для пересилання файлів. Він вказується у формі (тільки для POST) так:

У цьому випадку під час надсилання даних на сервер нічого не кодується. А сервер, зі свого боку, подивившись на Content-Type: multipart/form-data, зрозуміє, що прийшло.

Кодування даних.

Якщо Ви використовуєте тільки UTF-8, цей розділ вам не потрібен.

Усі параметри GET/POST, що йдуть на сервер, крім випадку multipart/form-data, кодуються в UTF-8. Не в кодуванні сторінки, а саме в UTF-8. Тому, наприклад, у PHP їх потрібно за необхідності перекодувати функцією iconv.

$name = iconv("UTF8","CP1251", $_GET["name"]);

Відповідь із сервера браузер сприймає саме в тому кодуванні, яке вказано в заголовку відповіді Content-Type. Тобто, знову ж таки, у PHP, щоб браузер сприйняв відповідь у windows-1251 і нормально відобразив дані на сторінці у windows-1251, потрібно надіслати заголовок з кодуванням у php-коді, наприклад так:

Header("Content-Type: text/plain; charset=windows-1251");

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

# у конфізі апача AddDefaultCharset windows-1251
.