Http 1

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

Поле заголовка запиту Host (розділ 14.23) ПОВИННО супроводжувати всі HTTP / 1.1 запити.

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

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

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

Методи можуть також мати властивість "idempotence" в тому сенсі, що побічні ефекти від N> 0 ідентичних запитів такі ж, як від одиночного запиту (за виключення помилок і проблем старіння). Методи GET, HEAD, PUT і DELETE володіють даними властивістю.

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

Якщо відповідь сервера - це не повідомлення про помилку, то відповідь НЕ МАЄ містити іншої інформації об'єкта, крім тієї, яку можна розглядати як опції з'єднання (наприклад Allow - можна розглядати як опцію сполуки, а Content-Type - немає). Відповіді на цей метод не кешуються.

Якщо запитуваний URI (Request-URI) НЕ зірочка ( "*"), то запит OPTIONS застосовується до опцій, які доступні при з'єднанні з зазначеним ресурсом. Якщо код стану відповіді - 200, то відповіді СЛІД містити будь-які поля заголовка, які вказують опціональні можливості, реалізовані сервером і застосовні до зазначеного ресурсу (наприклад, Allow), включаючи будь-які розширення, не визначені даною специфікацією, на додаток до відповідних загальним полях чи полях заголовка відповіді (response-header). Якщо запит OPTIONS передається через проксі-сервер, то останній редагує відповідь, виключаючи ті опції, які не передбачені можливості цього проксі-сервера.

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

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

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

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

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

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

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

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

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

Запити POST повинні відповідати вимогам передачі повідомлення, викладеним в розділі 8.2.

Запити з методом PUT, які містять об'єкт, зберігаються під запитуваною URI (Request-URI). Якщо Request-URI звертається до вже існуючого ресурсу, включений об'єкт СЛІД розглядати як модифіковану версію об'єкта, що знаходиться на початковому сервері. Якщо Request-URI не вказує на існуючий ресурс, і може інтерпретуватися агентом користувача як новий ресурс для запитів, початковий сервер може створити ресурс із даним URI. Якщо новий ресурс створений, то початковий сервер ПОВИНЕН повідомити агенту користувача про це за допомогою відповіді з кодом стану 201 (Створено, Created). Якщо існуючий ресурс модифікований, то для вказівки успішного завершення запиту СЛІД послати відповідь з кодом стану або 200 (OK), або 204 (Ні вмісту, No Content). Якщо ресурс не може бути створений або змінений для запитуваної URI (Request-URI), то СЛІД послати відповідь, що відображає характер проблеми. Одержувач об'єкта НЕ МАЄ ігнорувати заголовків Content- * (наприклад Content-Range), яких не розуміє або не реалізує, а ПОВИНЕН в даному випадку повернути відповідь з кодом стану 501 (Не реалізовано, Not Implemented).

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

Фундаментальна відмінність між POST і PUT запитами, відображено в різному значенні запитуваної URI (Request-URI). URI в запиті POST ідентифікує ресурс, який обробляє включений об'єкт. Цим ресурсом може бути процес, який бере дані, шлюз до певного іншій протоколу, або окремий об'єкт, який приймає анотації (accepts annotations). Навпаки, URI в запиті PUT ідентифікує об'єкт, включений у запит - агент користувача призначає даний URI включеному ресурсу, а сервер НЕ ПОВИНЕН намагатися застосувати запит до деякого іншого ресурсу. Якщо сервер бажає застосувати запит до іншого URI, він ПОВИНЕН послати відповідь з кодом 301 (Переміщений постійно, Moved Permanently); агент користувача МОЖЕ потім прийняти власне рішення щодо перепризначення запиту.

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

Запити PUT повинні підкорятися вимогам передачі повідомлень, викладеним в розділі 8.2.

Метод DELETE запитує початковий сервер про видалення ресурсу, ідентифікованого запитуваною URI (Request-URI). Цей метод МОЖЕ бути скасований людським втручанням (або іншими засобами) на первинному сервері. Клієнту не можна гарантувати, що операція була виконана, навіть якщо код стану, повернутий початковим сервером вказує на те, що дія була завершено успішно. Однак, сервера НЕ СЛІД відповідати про успішне виконання, якщо під час відповіді він передбачає видалити ресурс або перемістити його в недоступне стан.

Успішному відповіді СЛІД мати код стану 200 (OK), якщо відповідь включає об'єкт, що описує стан, або мати код стану 202 (Прийнято, Accepted), якщо дія ще не було вироблено, або мати код стану 204 (Ні вмісту, No Content), якщо відповідь повідомляє про успіх (OK), але не містить об'єкта.

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

Метод TRACE використовується для виклику віддаленого повернення повідомлення запиту на рівні додатку. Кінцевого одержувача запиту СЛІД відобразити отримане повідомлення назад клієнту як тіло об'єкта відповіді з кодом стану 200 (OK). Кінцевим одержувачем є або сервер походження, або перший проксі-сервер, або перший шлюз, який отримав нульове значення (0) в поле Max-Forwards в запиті (див. Розділ 14.31). Запит TRACE НЕ МАЄ містити об'єкта.

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

Якщо запит успішно виконаний, то відповіді СЛІД містити всі повідомлення запиту в тілі об'єкта (entity-body), а Content-Type слід бути рівним "message / http". Відповіді на цей метод НЕ ПОВИННІ кешуватися.