Http (hypertext transfer protocol)

Вступив в силу з:

HTTP (англ. H yperT ext T ransfer P rotocol - «протокол передачі гіпертексту») - мережевий протокол прикладного рівня передачі даних. Протокол заснований на технології "клієнт-сервер", тобто передбачається існування споживачів (клієнтів), які ініціюють з'єднання і надсилають запит, і постачальників (серверів), які очікують з'єднання для отримання запиту, виробляють необхідні дії і повертають назад повідомлення з результатом.

HTTP використовується в інших протоколах прикладного рівня, а також для передачі з сервера на клієнт будь-яких об'єктів: картинок, скриптів, CSS-файлів, файлів даних. Також він працює і у зворотний бік - для заливки на сервер файлів, відправки форм і т.п. AJAX-додатки також, очевидно, спілкуються з сервером по HTTP. Іноді HTTP використовується і для більш специфічних речей, наприклад, для керування вмістом сервера по протоколу WebDAV, XML-RPC, WebDAV.

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

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

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

Взаємодія клієнта (UA), кеша і вихідного сервера в протоколі HTTP

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

В інтересах надійності, рекомендується серверам ігнорувати будь-які порожні рядки, отримані, коли очікується Request-Line (рядок запиту). Іншими словами, якщо сервер Новомосковскет протокольний потік на початку повідомлення і отримує спочатку CRLF, він повинен ігнорувати CRLF.

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

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

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

Семантика методу змінюється на "умовний GET", якщо повідомлення-запит включає в себе поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match або If-Range. Метод умовного GET запитує, пересилання об'єкта тільки при виконанні вимог, описаних у відповідних полях заголовка. Метод умовного GET має на меті зменшити непотрібне використання мережі шляхом дозволу актуалізації кешування об'єктів без посилки множинних запитів або пересилання даних, які вже є у клієнта. Семантика методу GET змінюється на "частковий GET", якщо повідомлення запиту містить у собі поле заголовка Range. Запити часткового GET, які призначені для пересилання лише частини об'єкта. Метод часткового GET орієнтований на зменшення непотрібного мережевого обміну, допускаючи пересилання лише частини об'єкта, яка потрібна клієнтові, і не пересилаючи вже наявних частин.

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

Метод PUT вимагає, щоб вкладений об'єкт був запомнен з використанням Request-URI. Якщо Request-URI відноситься до вже існуючого ресурсу, то вкладений об'єкт слід розглядати як модифіковану версію об'єкта на вихідному сервері. Якщо Request-URI не вказує на існуючий ресурс і запитувач агент користувача може визначити цей URI як новий ресурс, вихідний сервер може створити ресурс з цим URI. Якщо новий ресурс створений, вихідний сервер повинен інформувати про це агента користувача, пославши код відгук 200 (OK) або 204 (No Content - ніякого вмісту) і тим самим, оголошуючи про успішно виконане запиті. Якщо ресурс не може бути створений або модифікований за допомогою Request-URI, повинен бути посланий відповідний код відгуку, який відображає характер проблеми. Одержувач об'єкта не повинен ігнорувати будь-який заголовок Content- * (наприклад, Content-Range), який він не зрозумів або не використав, а повинен в такому випадку повернути код відгуку 501 (Not Implemented - не використовувати).

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

Розширення бази даних за допомогою операції додавання (append).

Метод DELETE вимагає, щоб вихідний сервер знищив ресурс, ідентифікований Request-URI.

Метод TRACE використовується для того, щоб запустити віддалений цикл повідомлення-запиту на прикладному рівні. Кінцевий одержувач запиту повинен відіслати отримане повідомлення назад клієнту у вигляді тіла об'єкта (код = 200 (OK)). Кінцевим одержувачем є або вихідний сервер, або перший проксі або шлюз для отримання значення Max-Forwards (0) в запиті. Запит TRACE не повинен включати в себе об'єкт.

коди стану

Певні некоректні реалізації HTTP / 1.0 клієнтів генерують додаткові CRLF після запиту POST. Клієнт HTTP / 1.1 не повинен посилати CRLF до або після запиту.

діалог HTTP

Список кодів стану HTTP # 1xx | 1xx Informational ( «Інформаційний»)

У цей клас виділені коди, що інформують про процес передачі. У HTTP / 1.0 повідомлення з такими кодами повинні ігноруватися. У HTTP / 1.1 клієнт повинен бути готовий прийняти цей клас повідомлень як звичайний відповідь, але нічого відправляти сервера не потрібно. Самі повідомлення від сервера містять тільки стартову рядок відповіді і, якщо потрібно, кілька специфічних для відповіді полів заголовка. Проксі-сервери подібні повідомлення повинні відправляти далі від сервера до клієнта.

Список кодів стану HTTP # 2xx | 2xx Success ( «Успіх»)

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

Список кодів стану HTTP # 3xx | 3xx Redirection ( «Перенаправлення»)

Список кодів стану HTTP # 4xx | 4xx Client Error ( «Помилка клієнта»)

Клас кодів 4xx призначений для вказівки помилок з боку клієнта. При використанні всіх методів, крім HEAD. сервер повинен повернути в тексті листа гіпертекстове пояснення для користувача.

Список кодів стану HTTP # 5xx | 5xx Server Error ( «Помилка сервера»)

Коди 5xx виділені під випадки невдалого виконання операції з вини сервера. Для всіх ситуацій, крім використання методу HEAD. сервер повинен включати в тіло повідомлення пояснення, яке клієнт відобразить користувачеві.