Основний протокол для сторінок в інтернеті – HTTP. Цей протокол використовується кожен раз, коли ви заходите на новий сайт, коли на сайті відображається текст, картинка, коли ви натискаєте посилання.

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

HTTP — протокол, яким передається гіпертекст (HyperText Transfer Protocol).

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

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

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

Незалежно від назви браузера, до адресного рядка завжди за промовчанням додається назва протоколу: "http://". Ви можете і не бачити цей напис, якщо браузер його приховує. Але варто тільки скопіювати назву сайту, разом з ним потрібному місцівставиться протокол HTTP.

- Що означає приставка "http://" перед назвою сайту?
- Це означає, що ви звертаєтеся до ресурсу за протоколом HTTP.

Навіщо створили протокол HTTP

З його допомогою передають гіпертекстові документи, а простіше кажучи, сторінки на потрібних нам сайтах.

Приймає веб-сторінки клієнт (браузер), а дає сторінки сервер. Ця технологія так і називається – клієнт-серверна технологія.

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

Ще в 2006 році майже половина HTTP-трафіку Північної Америкискладалася з потокового звуку та відео.

Як працює HTTP

1. Браузер надсилає запит, запитуючи потрібну сторінку сервера.
2. Сервер отримує запит і починає шукати сторінку.
3. Браузер отримує відповідь від сервера з результатами запиту:
   • Код запитуваної сторінки та службова інформація – якщо сторінку знайдено.
   • Код помилки та службова інформація у разі збою.

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

Щоб ідентифікувати ресурси мережі, протокол HTTP користується глобальними URI. Відмінність HTTP від ​​інших протоколів – він не зберігає свого стану. Тобто не зберігається стан між парою «запит-відповідь».

HTTP – це не єдиний протокол, який використовують в Інтернеті. Також використовуються:

• FTP (File Transfer Protocol) – протокол передачі файлів.
• POP (Post Office Protocol) та SMTP (Simple Mail Transport Protocol) – для обміну повідомленнями електронної пошти.
• SHTTP (Secure Hypertext Transfer Protocol) - шифрований різновид HTTP. Інформація, що передається за цим протоколом, кодується. Зазвичай безпека важлива у разі обміну конфіденційними даними.

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

Березень 1991 - Тім Бернерс-Лі запропонував використовувати HTTP.

Саме Бернерс-Лі розробив усе перше, що пов'язане з Інтернетом: браузер, сервер, гіперпосилання, перший сайт (info.cern.ch) Як виглядав перший сайт, можна побачити за посиланням.

Версії HTTP з часом удосконалюються, популярною стала версія HTTP 1.1, яка дозволяє на тривалий час залишати відкритим з'єднання сервера з браузером, що зробило протокол ефективнішим.

У 2015 році з'явився HTTP/2, який став бінарним, змінилися способи, якими розбивали інформацію на фрагменти.

Безпека протоколу HTTP

Сам HTTP не має на увазі шифрування інформації. Але є розширення для протоколу, яке вміє упаковувати дані в протокол SSLабо TLS.

HTTPS (S — Secure) — популярне рішення, яке не дозволяє перехоплювати інформацію, що передається, і захистити інформацію від MITM-атак «man-in-the-middle» або атака посередника.

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

З чого складається HTTP

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

1. Стартовий рядок, який визначає тип повідомлення.
2. Заголовки, з допомогою яких характеризують тіло повідомлення.
3. Тіло повідомлення, де містяться потрібні дані.

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

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

Сутність роботи HTTP

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

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

Тепер розкриємо суть поняття HTTP протокол

HTTP (англ. HyperText Transfer Protocol)– процес, згідно з яким проводяться всі види обміну інформацією у всесвітній мережі Інтернет.

Нас як веб-розробників цікавить лише сам процес обміну та виведення інформації.

Синхронізований протокол

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

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

Як здійснюється запит?

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

1. Насамперед здійснюється DNS-запит, який має перетворити адресу сайту з URI формату в IP (числова форма URI-адреси). Саме такий формат адреси використовується у Всесвітній мережі.
2. Після визначення IP встановлюється зв'язок між сервером та HTTP клієнтом.
3. Пересилання запиту.
4. Затримка, в яку входить пересилання інформації на сервер, її обробка та надсилання відповіді на запит. Програмісти називають цей часовий проміжок очікуванням відповіді.
5. Отримайте відповідь на запит.

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

Зі переліку всіх етапів досить тривалим є перший. На початку розвитку протокол HTTPвикористовував застарілу схему обробки даних, яка передбачала розрив зв'язку після отримання відповіді на необхідний запит. Це дуже гальмувало процес роботи в інтернет-просторі. Однак після того, як вийшла нова стандартизація роботи протоколу HTTPверсії 1.1, став доступним новий режим роботи з'єднання keep-alive, згідно з яким зв'язок став нерозривним. Внаслідок цього після обробки першого запиту не потрібно знову проходити перший етап, а відразу переходити до другого.

Нотатка

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

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

Така форма роботи зводить шанси сайтів нанівець у конкурентній боротьбі з десктопними додатками. Звідси випливає і перший спосіб прискорити роботу сайту – потрібно мінімізувати кількість звернень до сервера, прописаних у коді.

Паралельне з'єднання HTTP

Щоб вирішити проблему великого часу очікування та переривання зв'язку з хостом, було створено паралельну схему зв'язку між клієнтом та сервером. Іншими словами, можна одночасно встановити з'єднання з кількома хостами. Розробники стандарту HTTP 1.1радять підключати не більше 2 каналів з'єднання одночасно. Але слід враховувати, що специфікація побачила світ ще за часів стародавніх динозаврів. Зараз браузери легко підтримують зв'язок із 4 каналами одночасно за замовчуванням, а якщо поритися в налаштуваннях клієнта, цей показник можна збільшити до 8.

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

Конвеєрне HTTP з'єднання

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

Завдяки цьому нововведенню стало також можливим скорочення кількості TCP/IP-пакетів. Таким чином, можна в один такий пакет помістити декілька HTTP-запитів. Внаслідок цього покращиться не лише робота протоколу, а й підвищиться ефективність функціонування мережі Інтернет загалом.

Підводячи підсумок

На сьогоднішній день специфікація HTTP 1.1є морально застарілим зведенням правил. Над її модернізацією ведуться роботи вже досить давно, яскравим прикладомцього є HTTP-NGі SPDY. Розвивати HTTPможна і силами вдосконалення мови програмування сайтів HTML5. Всі ці процеси дозволять прискорити роботу протоколу, проте правило мінімізації звернення до сервера, що дозволить збільшити швидкість роботи ресурсу, завжди буде актуальним.

Для World Wide Web. Такі протоколи є структурованим текстом, який використовує логічні зв'язки(Гіперпосилання) між вузлами, що містять певні дані. Таким чином, це спосіб обміну або передачі гіпертексту.

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

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

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

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

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

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

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

22.04.05 13625

Призначення протоколу

HyperText Transfer Protocol (HTTP)- Це протокол високого рівня(а саме рівня додатків), що забезпечує необхідну швидкість передачі даних, потрібну для розподілених інформаційних систем гіпермедіа. HTTP використовується проектом World Wide Web з 1990 року.

Практичні інформаційні системивимагають більшого, ніж примітивний пошук, модифікація та інструкція даних. HTTP/1.0 надає відкриту множину методів, які можуть бути використані для вказівки цілей запиту. Вони побудовані на дисципліні посилань, де для вказівки ресурсу, до якого має бути застосований даний метод, використовується Універсальний Ідентифікатор Ресурсів (Universal Resource Identifier — URI), як місцезнаходження (URL) або ім'я (URN). Формат повідомлень подібний до формату Internet Mail або Multipurpose Internet Mail Extensions (MIME-Многоцільове Розширення Пошти Internet).

HTTP/1.0 використовується також для комунікацій між різними користувальницькими переглядачами та шлюзами, що дають гіпермедіа доступ до існуючих Internet протоколам, такі як SMTP, NNTP, FTP, Gopher і WAIS. HTTP/1.0 розроблений, щоб дозволяти таким шлюзам через proxy сервери, без будь-якої втрати передавати дані за допомогою згаданих протоколів попередніх версій.

Загальна структура

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

У Internet комунікації зазвичай ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням – TCP 80, але також можуть бути використані й інші номери портів – це не виключає можливості використовувати HTTP як протокол верхнього рівня.

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

Загальні поняття

Запит – це повідомлення, яке надсилається клієнтом серверу.
Перший рядок цього повідомлення включає метод, який повинен бути застосований до запитуваного ресурсу, ідентифікатор ресурсу і використовувану версію протоколу. Для сумісності з протоколом HTTP/0.9 існує два формати HTTP запиту:

Запит = Простий-Запит | Повний-Запит Простий-Запит = "GET" SP Запитуваний-URI CRLF Повний-Запит = Рядок-Статус *(Загальний-Заголовок | Заголовок-Запиту | Заголовок-Змісту) CRLF [ Зміст-Запиту ]

Якщо HTTP/1.0 сервер отримує Простий-Запит, він повинен відповідати простим-відповіддю HTTP/0.9. HTTP/1.0 клієнт, здатний обробляти Повний Відповідь, ніколи не повинен посилати Простий Запит.

Рядок Статус

Рядок Статус починається з рядка з назвою методу, за яким слідує URI-Запиту і версія протоколу, що використовується. Рядок Статус закінчується символами CRLF. Елементи рядка поділяються пробілами (SP). У Рядку Статус не допускаються символи LF і CR, за винятком послідовності CRLF.

Рядок-Статус = Метод SP URI-Запиту SP Версія-HTTP CRLF

Слід зазначити, що відмінність Рядки Статус Повного-Запиту від Рядки Статус Простого- Запитуполягає у присутності поля Версія-HTTP.

Метод

У полі Метод вказується метод, який має бути застосований до ресурсу, що ідентифікує URI-Запиту. Назви методів чутливі до регістру. Існуючий перелік методів може бути розширений.

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" | додатковий метод

Список методів, що допускаються окремим ресурсом, може бути зазначений у полі Заголовок-Зміст «Баллів». Тим не менш, клієнт завжди повідомляє сервер через код статусу відповіді, чи допускається застосування даного методудля зазначеного ресурсу, оскільки допустимість застосування різних методів може динамічно змінюватися. Якщо цей метод відомий серверу, але не допускається для зазначеного ресурсу, сервер повинен повернути код статусу "405 Method Not Allowed" і код статусу "501 Not Implemented", якщо метод не відомий або не підтримується даним сервером. Загальні методи HTTP/1.0 описані нижче.

GET

Метод GET служить для отримання будь-якої інформації, що ідентифікована URI-Запиту. Якщо URI- Запиту посилається на процес, що видає дані, як відповідь виступатимуть дані, згенеровані цим процесом, а не код самого процесу (якщо тільки це не є вихідними даними процесу).

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

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

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

HEAD

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

POST

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

• Анотація існуючих ресурсів
• Додавання повідомлень до груп новин, поштових списків або подібних груп статей
• Доставка блоків даних процесам, які обробляють дані
• Розширення баз даних через операцію додавання

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

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

Якщо в результаті обробки запиту POST було створено новий ресурс, відповідь повинна мати код статусу, що дорівнює «201 Created», і містити URI нового ресурсу.

PUT

Метод PUT запитує сервер про збереження Тіло-Запиту під URI, що дорівнює URI-Запиту. Якщо URI-Запит посилається на вже існуючий ресурс, Тіло-Запит має розглядатися як модифікована версіяданого ресурсу. Якщо ресурс, на який посилається URI-Запиту не існує, і даний URI може розглядатися як опис нового ресурсу, сервер може створити ресурс з даним URI. Якщо було створено новий ресурс, сервер повинен інформувати клієнта, що направив запит, через відповідь з кодом статусу «201 Created». Якщо існуючий ресурс був модифікований, має бути надіслана відповідь «200 OK», для інформування клієнта про успішне завершення операції. Якщо ресурс із зазначеним URI не може бути створений або модифікований, має бути надіслано відповідне повідомлення про помилку.

Фундаментальна різниця між методами POST та PUT полягає у різному значенні поля URI-Запиту. Для методу POST даний URI вказує ресурс, який керуватиме інформацією, що міститься в тілі запиту, як придатком. Ресурс може бути обробним дані процесом, шлюзом в якийсь інший протокол, або окремим ресурсом, що допускає інструкції. На противагу цьому, URI для запиту PUT ідентифікує інформацію, що міститься в Зміст-Запит. PUT, що використовує запит, точно знає який URI він збирається використовувати, і одержувач запиту не повинен намагатися застосувати цей запит до якогось іншого ресурсу.

DELETE

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

LINK

Метод LINK встановлює взаємозв'язки між існуючим ресурсом, зазначеним у URI-Запиті, та іншими існуючими ресурсами. Відмінність методу LINK від інших методів, що допускають встановлення посилань між документами, полягає в тому, що метод LINK не дозволяє передавати в запиті Тіло-Запиту, і в тому, що в результаті цього методу не створюються нові ресурси.

UNLINK

Метод UNLINK видаляє один або більше посилань для ресурсу, зазначеного в URI- Запиту. Ці взаємозв'язки можуть бути встановлені за допомогою методу LINK або іншого методу, що підтримує заголовок «Link». Видалення посилання на ресурс не означає, що ресурс припиняє існування або стає недоступним для майбутніх посилань.

Поля Заголовок-Запиту

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

Заголовок-Запиту = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | від | If-Modified-Since | Pragma | Referer | User-Agent | extension-header

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

Нижче буде розглянуто деякі поля заголовка запиту.

від

У разі присутності поля From, воно має містити повну електронну адресу користувача, який управляє програмою-агентом, що здійснює запити. Ця адреса повинна бути задана у форматі, визначеному в RFC 822. Формат даного полянаступний: From = "From" ":" специфікація адреси. Наприклад:

Від: [email protected]

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

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

If-Modified-Since

Поле заголовка If-Modified-Since використовується з методом GETдля того, щоб зробити його умовним: якщо запитуваний ресурс не змінювався у часі, вказаному в цьому полі, копію цього ресурсу не буде повернуто сервером; натомість, буде повернено відповідь «304 Not Modified» без Тіла-Відповіді.

If-Modified-Since = "If-Modified-Since" ":" HTTP-дата

Приклад використання заголовка:

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

User-Agent

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

User-Agent = "User-Agent" ":" 1*(продукт) продукт = рядок ["/" версія-продукту] версія-продукту = рядок

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

Структура відповіді

Після отримання та інтерпретації запиту, сервер надсилає відповідь відповідно до наступної форми:

Відповідь = Простий-Відповідь | Повний-Відповідь Простий-Відповідь = [ Зміст-Відповіді ] Повний-Відповідь = Рядок-Статус *(Загальний-Заголовок | Заголовок-Відповіді | Заголовок-Змісту) CRLF [ Зміст-Відповіді ]

Простий Відповідь повинен надсилатися тільки у відповідь на HTTP/0.9 Простий Запит, або якщо сервер підтримує лише обмежений HTTP/0.9 протокол. Якщо клієнт посилає HTTP/1.0 Повний-Запит і отримує відповідь, яка не починається з Рядки-Статус, він повинен припускати, що відповідь сервера являє собою Простий-Відповідь, і обробляти його відповідно до цього. Слід зазначити, що Простий-Відповідь складається тільки з інформації, що запитується (без заголовків) і потік даних припиняється в той момент, коли сервер закриває сеанс зв'язку.

Рядок Статус

Перший рядок Повного-Запиту є Рядком-Статус, що складається з версії протоколу, за якою слідує цифровий код статусу та асоційована з ним текстова пропозиція. Всі елементи Рядки-Статус розділені пробілами. Не дозволені символи CR та LF, за винятком завершальної послідовності CRLF.

Рядок-Статус=Версія-HTTP SP Статус-Код SP Фраза-Пояснення.

Оскільки Рядок-Статус завжди починається з версії протоколу «HTTP/» 1*ЦИФРА «.» 1*ЦИФРА (наприклад HTTP/1.0), існування цього виразу розглядається як основне визначення того, чи є відповідь Простим-Ответом, чи Повним-Ответом. Хоча формат Простого-Відповіді не виключає появи такого рядка (що призвело б до неправильної інтерпретації повідомлення відповіді та прийняття його за Повну-Відповідь), ймовірність такої появи близька до нуля.

Статус-код та пояснення до нього

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

Перша цифра Статус-Коду призначена визначення класу відповіді. Останні дві цифри не виконують жодної ролі, що категоризує. Існує 5 значень для першої цифри:

1. 1xx: Інформаційний — Не використовується, але зарезервований для використання у майбутньому
2. 2x: Успіх - Запит був повністю отриманий, зрозумілий, і прийнятий до обробки.
3. 3xx: Перенаправлення — Клієнту слід вжити подальших дій для успішного виконання запиту. Необхідне додаткова діяіноді може бути виконано клієнтом без взаємодії з користувачем, але настійно рекомендується, щоб це мало місце лише в тих випадках, коли метод, який використовується у запиті байдужий (GET або HEAD).
4. 4xx: Помилка клієнта — Запит, який містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису тих випадків, коли помилку було допущено з боку клієнта. Якщо клієнт ще не завершив запит, коли він отримав відповідь із Статус-кодом-4xx, він повинен негайно припинити передачу даних серверу. Даний тип Статус-кодів застосовується для будь-яких методів, що вживаються у запиті.
5. 5xx: Помилка Сервера — Сервер не зміг відповідати на коректно поставлений запит. У цих випадках
   сервер або знає, що він припустився помилки, або не здатний обробити запит. За винятком відповідей на запити HEAD, сервер посилає опис помилкової ситуації і те, чи є цей стан тимчасовим або постійним, у Зміст-Відповіді. Даний тип Статус-кодів застосовується для будь-яких методів, що вживаються у запиті.

Окремі значення Статус-Кодів та відповідні їм Фрази-Пояснення наведено нижче. Дані Фрази-Пояснення тільки рекомендуються — вони можуть бути заміщені будь-якими іншими фразами, що зберігають сенс і протоколом, що допускаються.

Статус-Код = "200"; Добре | "201"; Created | "202"; Прийнято | "203"; Provisional Information | "204"; No Content | "300"; Multiple Choices | "301"; Moved Permanently | "302"; Moved Temporarily | "303"; Метод | "304"; Not Modified | "400"; Bad Request | "401"; Unauthorized | "402"; Payment Required | "403"; Forbidden | "404"; Not Found | "405"; Method Not Allowed | "406"; None Acceptable | "407"; Proxy Authentication Required | "408"; Request Timeout | "409"; Конфлікт | "410"; Gone | "500"; Internal Server Error | "501"; Not Implemented | "502"; Bad Gateway | "503"; Service Unavailable | "504"; Gateway Timeout | Код-Розширення Код-Розширення = 3ЦИФРА Фраза-Пояснення = рядок *(SP рядок)

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

Поля Заголовок-Відповіді

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

Заголовок-Відповіді = Public | Retry-After | Server | WWW-Authenticate | extension-header

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

Загальні поняття

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

Поля Заголовок-Змісту

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

Деякі з полів заголовка змісту описані нижче.

Allow

Поле заголовка Allow є переліком методів, які підтримує ресурс, ідентифікований URI-Запиту. Призначення цього поля - точне інформування одержувача про допустимі методи, асоційовані з ресурсом; це поле має бути у відповіді зі статусом кодом «405 Method Not Allowed».

Allow = "Allow" ":" 1#метод

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

Allow: GET, HEAD, PUT

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

Content-Length

Поле Content-Length вказує розмір тіла повідомлення, надісланого сервером у відповідь на запит або, у разі запиту HEAD, розмір тіла повідомлення, яке було надіслано у відповідь на запит GET.

Content-Length = "Content-Length" ":" 1*ЦИФРА

Наприклад:

Content-Length: 3495

Хоча це не обов'язково, але все ж додаткам настійно рекомендується використовувати це поле для аналізу розмірів повідомлення, що передається, незалежно від типу інформації, що міститься в ньому. Для поля Content-Length допустимим є будь-яке ціле значення більше нуля.

Content-Type

Поле заголовка Content-Type ідентифікує тип інформації в тілі повідомлення, яка надсилається стороні, що отримує, або, у разі методу HEAD, тип інформації (середовища), який був би посланий, якщо використовувався метод GET.

Content-Type = "Content-Type" ":" тип-середовища

Типи середовищ визначено окремо.
Приклад:

Content-Type: text/html; charset=ISO-8859-4

Поле Content-Type не має значення за промовчанням.

Last-Modified

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

Last-Modified = "Last-Modified" ":" HTTP-дата

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

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

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

Під тілом повідомлення розуміється Зміст-Запиту або Зміст-Відповіді відповідно. Тіло повідомлення, якщо воно є, надсилається в HTTP/1.0 запиті або відповіді у форматі та кодуванні, що визначаються полями Заголовок-Змісту.

Тіло-Повідомлення = *OCTET (де OCTET це будь-який 8-бітний символ)

Тіло повідомлення включається у запит, лише якщо метод запиту має на увазі його наявність. Для специфікації HTTP/1.0 такими методами є POST та PUT. Загалом, на присутність тіла повідомлення вказує присутність таких полів заголовка змісту, як Content-Length та/або Content-Transfer-Encoding, у запиті, що передається.

Що стосується повідомлень-відповідей, наявність тіла повідомлення у відповіді залежить від методу, який був використаний у запиті, та Статус-коду. Всі відповіді на запити HEAD не повинні містити тіло повідомлення, хоча наявність деяких полів заголовка повідомлення може вказувати на можливу присутність. Відповідно, відповіді «204 No Content», «304 Not Modified» та «406 None Acceptable» також не повинні включати тіло повідомлення.

Добре погано

Протокол передачі гіпертексту HTTP (Hypertext Transfer Protocol, RFC 1945, 2068) призначений передачі гіпертекстових документів від сервера до клієнта. Протокол HTTPвідноситься до протоколів прикладного рівня. Відповідно до RFC, транспортним протоколомдля нього повинен бути протокол з встановленням з'єднання, надійною передачею даних та без збереження меж між повідомленнями. Насправді у переважній більшості випадків транспортним протоколом для HTTP є протокол TCP, причому сервер HTTP (сервер Web) перебуває у стані очікування з'єднання з боку клієнта стандартно порту 80 TCP, а клієнт HTTP ( браузер Web) є ініціатором з'єднання.

У термінах Web все, чого може отримати доступ користувач, – документи, зображення, програми, – називається ресурсами. Кожен ресурс має унікальну для Web адресу, яку називають універсальним ідентифікатором ресурсу (URI – Universal Resource Identifier). У загальному випадку URI виглядає так:

protocol://user:password@host:port/path/file?paremeters#fragment

Окремі поля URI мають такий зміст:

protocol - прикладний протокол, з якого отримують доступом до ресурсу;

user - користувач, від імені якого отримують доступ до ресурсу або сам користувач як ресурс;

password – пароль користувача для аутентифікації при доступі до ресурсу;

host - IP-адреса або ім'я сервера, на якому розташований ресурс;

port - номер порту, у якому працює сервер, надає доступом до ресурсу;

path - шлях до файлу, що містить ресурс;

file – файл, що містить ресурс;

parameters – параметри для обробки ресурсом-програмою;

fragment - точка у файлі, з якої слід відображати ресурс.

Взаємодія між клієнтом та сервером Web здійснюється шляхом обміну повідомленнями. HTTP-повідомлення поділяються на запити клієнта серверу та відповіді сервера клієнту.

Повідомлення запиту та відповіді мають загальний формат. Обидва типи повідомлень виглядають наступним чином: спочатку йде початковий рядок (start-line), потім, можливо, одне або кілька полів заголовка, званих також просто заголовками, потім порожній рядок (тобто рядок, що складається з символів CR і LF), вказує кінець полів заголовка, а потім, можливо, тіло повідомлення:

початковий рядок

поле заголовка 1

поле заголовка 2

поле заголовка N

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

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

загальні заголовки (general-headers), які можуть бути як у запиті, і у відповіді;

заголовки запитів (request-headers), які можуть бути лише у запиті;

заголовки відповідей (response-headers), які можуть бути лише у відповіді;

заголовки об'єкта (entity-headers), які відносяться до тіла повідомлення та описують його вміст.

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

Таблиця 1
Заголовки протоколу HTTP
Заголовок	Призначення
Заголовки об'єкту
	Перераховує підтримувані сервером методи
Content-Encoding	Спосіб, яким закодовано тіло повідомлення, наприклад, з метою зменшення розміру
	Довжина повідомлення в байтах
	Тип вмісту та, можливо, деякі параметри
	Унікальний тег ресурсу на сервері, що дозволяє порівнювати ресурси
	Дата та час, коли ресурс на сервері буде змінено, і його потрібно отримувати заново
	Дата та час останньої модифікації вмісту
Заголовки відповіді
	Число секунд, через яке потрібно повторити запит для отримання нового вмісту
	URI ресурсу, до якого потрібно звернутися для отримання вмісту
	Дата і час або кількість секунд, через які потрібно повторити запит, щоб отримати успішну відповідь
	Назва програмного забезпечення сервера, що надіслав відповідь
Заголовки запиту
	Типи вмісту, що "розуміє" клієнт і може відтворити
	Кодування символів, у яких клієнт може приймати текстовий вміст
	Спосіб, яким сервер може закодувати повідомлення
	Хост та номер порту, з якого запитується документ
If-Modified-Since If-Unmodified-Since	Заголовки запиту для умовного звернення до ресурсу
	Запит частини документа
	Назва програмного забезпечення клієнта
Загальні заголовки
	Вказує серверу на завершення (close) чи продовження (keep-alive) сеансу
	Дата та час формування повідомлення

Детальний опис заголовків HTTP/1.0 можна знайти в RFC 2068.

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

Повідомлення запиту від клієнта до сервера складається з рядка запиту (request-line), заголовків (загальних, запитів, об'єкта) та, можливо, тіла повідомлення. Рядок запиту починається з методу, потім ідентифікатор запитуваного ресурсу, версія протоколу і завершальні символи кінця рядка:

<Метод> <Идентификатор> <Версия HTTP>

Метод вказує команду протоколу HTTP, яку потрібно застосувати до запитуваного ресурсу. Наприклад, метод GET говорить про те, що клієнт хоче одержати вміст ресурсу. Ідентифікатор визначає запитуваний ресурс. Версія HTTP позначається рядком такого виду:

HTTP/<версия>.<подверсия>

У RFC 2068 представлений протокол HTTP/1.1.

Розглянемо основні методи протоколу HTTP.

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

Якщо відповідь сервера – це повідомлення про помилку, то заголовки об'єкта містять інформацію, яку можна як опції з'єднання. Наприклад, у заголовку Allow перераховані всі методи, які підтримує сервер для даного ресурсу.

Якщо ідентифікатор запитуваного ресурсу – зірочка ("*"), запит OPTIONS призначений для звернення до сервера в цілому.

Якщо ідентифікатор запитуваного ресурсу – не зірочка, запит OPTIONS застосовується до опцій, які доступні при з'єднанні з вказаним ресурсом.

Метод GET дозволяє отримувати будь-яку інформацію, пов'язану із запитуваним ресурсом. У більшості випадків, якщо ідентифікатор запитуваного ресурсу вказує на документ (наприклад, документ HTML, текстовий документ, графічне зображення, відео), сервер повертає вміст цього документа (вміст файлу). Якщо запитуваний ресурс є додатком (програмою), що формує у процесі роботи деякі дані, то тілі повідомлення відповіді повертаються ці дані, а чи не двійковий образ виконуваного файла. Це використовується, наприклад, для створення програм CGI. Якщо ідентифікатор запитуваного ресурсу вказує на директорію (каталог, папку), то, залежно від налаштувань сервера, може бути повернутий або вміст директорії (список файлів), або вміст одного з файлів, що знаходиться в цій директорії (як правило, index.html або Default.htm). У разі запиту папки її ім'я може вказуватись як із символом "/" на кінці, так і без нього. За відсутності на кінці ідентифікатора ресурсу даного символу сервер видає одну з відповідей із перенаправленням (з кодами статусу 301 або 302).

Одним із різновидів методу GET є "умовний GET" ("conditional GET"), при якому повідомлення запиту включає заголовки запиту If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, або If-Range . Умовний метод GET запитує передачу об'єкта, лише якщо він відповідає умовам, описаним у наведених заголовках. Наприклад, за наявності заголовка If-Modified-Since вміст запитуваного ресурсу буде отримано тільки в тому випадку, якщо він не змінювався після моменту часу, зазначеного як значення даного заголовка. Умовний метод GET призначений для зменшення непотрібного завантаження мережі, оскільки дозволяє не завантажувати повторно збережені клієнтом дані.

Розрізняють також "частковий GET" ("partial GET"), коли повідомлення запиту включає заголовок запиту Range. Частковий GET запитує передачу лише частини об'єкта. Частковий метод GET призначений для зменшення непотрібного завантаження мережі за рахунок запиту лише частини об'єкта, коли інша частина вже завантажена клієнтом. Значення заголовка Range є рядок "bytes=" з наступним зазначенням діапазону байтів, які необхідно отримати. Байти нумеруються з 0. Початковий і кінцевий байти діапазону поділяються символом "-". Як початковий, так і кінцевий байти в діапазоні можуть бути відсутніми. Якщо потрібно отримати кілька діапазонів, то вони перераховуються через кому. Якщо деякі з перерахованих діапазонів перетинаються, сервер здійснює їх об'єднання. Повідомлення відповіді у разі запиту з частковим методом GET має містити заголовок Content-Range, в якому вказується діапазон, що передається. Якщо сервер передає кілька діапазонів, що не перетинаються, то заголовок Content-Type приймає спеціальне значення "multypart/byteranges". Тіло повідомлення розбивається на частини, розділені згенерованим сервером роздільником і переданим як параметр заголовка Content-Type. Кожна окрема частинамістить власні заголовки Content-Typeі Content-Range з порожнім рядкомперед вмістом діапазону.

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

Метод POST використовується для запиту, при якому сервер, що адресується приймає дані, включені в тіло повідомлення (об'єкт) запиту, і відправляє їх на обробку додатку, зазначеному як запитуваний ресурс. POST розроблений для того, щоб загальним методомреалізувати такі функції:

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

реєстрація повідомлення на електронній дошці оголошень (BBS), конференціях новин (newsgroups), списках розсилки (mailing lists) або подібній групі статей;

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

виконання запитів до баз даних (БД);

Фактично функція, що виконується методом POST, визначається додатком, який вказує ідентифікатор запитуваного ресурсу. Поряд із методом GET, метод POST використовується при створенні програм CGI. Браузер може формувати запити з методом POST під час надсилання форм. Для цього елемент FORM документа HTML, що містить форму, повинен мати атрибут метод зі значенням POST.

Програма, запуск якої ініціюється методом POST, може виконати дію на сервері і не передати жодного вмісту як результат роботи. Залежно від того, включає відповідь тіло повідомлення, що описує результат, чи ні, код стану відповіді може бути як 200 (OK), так і 204 (Немає вмісту, No Content).

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

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

Відмінність між методами POST і PUT полягає у різному значенні ідентифікатора запитуваного ресурсу. URI у запиті POST ідентифікує ресурс, який обробляє об'єкт, що включений в тіло повідомлення. Цим ресурсом може бути програма, яка приймає дані. Навпаки, URI в запит PUTідентифікує об'єкт, включений у запит у вигляді тіла повідомлення, тобто користувальницький агент призначає даний URI включеного ресурсу.

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

Метод TRACE використовується для повернення надісланого запиту на рівні протоколу HTTP. Отримувач запиту (сервер Web) відправляє отримане повідомлення клієнту як тіло повідомлення відповіді з кодом стану 200 (OK). Запит TRACE не повинен містити тіла повідомлення.

TRACE дозволяє клієнту бачити, що отримує на іншому кінці сервер та використовувати ці дані для тестування або діагностики.

Якщо запит успішно виконано, відповідь містить усі повідомлення запиту в тілі повідомлення відповіді, а заголовок об'єкта Content-Type має значення "message/http".

Детальну інформацію про методи протоколу HTTP/1.1 можна знайти у RFC 2068.

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

Перший рядок відповіді – це рядок стану (Status-Line). Вона складається з версії протоколу, числового коду стану, що пояснює фрази, розділених пробілами та завершальних символів кінця рядка:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Версія протоколу має той самий сенс, що у запиті.

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

Перша цифра коду стану визначає клас відповіді. Останні дві цифри немає певної ролі класифікації. Є 5 значень першої цифри:

1xx: Інформаційні коди – запит отримано, продовжується обробка.

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

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

4xx: Коди помилок клієнта – запит має помилку синтаксису або може бути виконано.

5xx: Коди помилок сервера – сервер не в змозі виконати припустимий запит.

Пояснення для кожного коду стану перераховані в RFC 2068 і є рекомендованими, але можуть бути замінені на еквівалентні без обмежень з боку протоколу. Наприклад, у локалізованих російськомовних версіях HTTP серверів ці фрази замінені російськими. У табл. 2 наведено коди відповідей HTTP-сервера.

Таблиця 2
Коди відповідей сервера HTTP
	Пояснювальна фраза згідно
1xx: Інформаційні коди
		Продовжувати
2xx: Успішні коди
		Немає вмісту
		Скинути вміст
	Partial Content	Частковий вміст
3xx: Коди перенаправлення
	Moved Temporarily	Тимчасово переміщено
		Не модифіковано
4xx: Коди помилок клієнта
		Зіпсований запит
		Несанкціоновано
		НЕ знайдений
	Method Not Allowed	Метод не дозволений
	Request Timeout	Минув час очікування запиту
		Конфлікт
	Length Required	Потрібна довжина
	Request Entity Too Large	Об'єкт запиту занадто великий

Закінчення табл. 2
	Пояснювальна фраза згідно	Еквівалентна фраза, що пояснює російською мовою
5xx: Коди помилок сервера
	Internal Server Error	Внутрішня помилка сервера
	Not Implemented	Не реалізовано
	Service Unavailable	Сервіс недоступний
	HTTP Version Not Supported	Версія HTTP, що не підтримується

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

За рядком стану слідують заголовки (загальні, відповіді та об'єкта) і, можливо, тіло повідомлення.

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