POST (HTTP)

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

POST — один з багатьох методів запиту, що підтримуються протоколом передачі данних HTTP, який використовується у всесвітній мережі Інтернет. Метод POST призначений для запиту, при якому веб-сервер приймає дані збережені в тілі повідомлення, для зберігання.[1] Метод часто використовується для завантаження файлу або передачі заповненої веб-форми.

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

Дані POST-запитів[ред.ред. код]

Всесвітня мережа Інтернет і протокол HTTP базуються на методах запитів, включаючи POST, GET, PUT, DELETE і ряд інших. Веб-браузери зазвичай використовують тільки GET і POST, але REST онлайн-додатки вимагаються підтримки і багатьох інших. Метод POST призначений для відправки запиту нової сутності на сервер, так що вона буде зберігатися як подресурс ресурсу, ідентифікованого URI. Наприклад, для URI http://example.com/customers за допомогою POST запитів можна було б представляти нових клієнтів, кожен з яких містив би ім'я, адресу та контактні дані. Розробники сайтів відійшли від цієї концепції з двох причин. По-перше, немає ніяких технічних причин для URI текстуально описувати підлеглі веб-ресурси, на яких будуть збережені дані послані методом POST. Справді, остання частина URI більш ймовірно опише сторінку обробки веб-додатку та його технології, наприклад http://example.com/applicationform.php. По-друге, з огляду на природне обмеження більшості веб-браузерів роботи тільки методами GET та POST, розробники розуміли необхідність додавання додаткових можливостей в метод POST, включаючи зміну існуючих записів та їх видалення.

Спроби виправити перший недолік почалися ще в 1998 році. Фреймворки веб-додатків, такі як Ruby on Rails та інші допомагали розробникам надавати своїм користувачам веб-адреси, зручні для сприйняття людиною. Що стосується другого пункту, можна написати клієнтські сценарії або автономні програми, які будуть використовувати інші методи HTTP, перетворюючи їх потім в метод POST.

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

Бувають випадки, коли HTTP GET не підходить навіть для отримання даних. Прикладом є ситуація, коли велика кількість даних повинно бути записана в URL. Браузери і веб-сервери можуть мати обмеження на довжину URL, які вони обробляють без помилки. URL-кодування зарезервованих символів у адресі і рядку запиту може значно збільшити довжину, в той час як HTTP-сервер Apache може обробляти до 4000 символів в URL, Microsoft Internet Explorer обмежує довжину будь-якого URL 2048 символами.

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

Використання для подання веб-форм[ред.ред. код]

Коли веб-браузер відправляє POST-запит з елементами веб-форми, за замовчуванням інтернет-тип даних медіа це: application/x-www-form-urlencoded.[2] Це формат для кодування пар ключ-значення з можливістю дублювання ключів. Кожна пара ключ-значення відділяється символом &, ключ відділений від значення символом =. У ключах і значеннях пробіли замінюються на символ +, і потім, використовуючи URL-кодування, замінюються всі не літеро-цифрові символи.[3]

Name: Jonathan Doe
Age: 23
Formula: a + b == 13 %!

Буде закодовано таким чином:

Name=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21

Починаючи з HTML 4.0, форми можуть також представити дані в multipart/form, як визначено в RFC 2388 (див. Також RFC 1867 для більш ранньої експериментальної версії визначеної як розширення HTML 2.0 і згадується в HTML 3.2).

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

Вплив на стан сервера[ред.ред. код]

У RFC 2616 методі POST-запит повинен бути використаний для будь-якого контексту, в якому запит не ідемпотентний: тобто, він викликає зміну стану сервера кожного разу при виконанні, такі як відправка коментаря до повідомлення в блозі або інтернет-голосування. На практиці, метод GET часто зарезервований, не просто для ідемпотентних дій, але й для нульпотентних, тобто без побічних ефектів (на відміну від «без побічних ефектів при другому і наступних запитах» як з Ідемпотентними операціями). З цієї причини сайти пошукових систем, таких як індексатори пошукових систем зазвичай використовують виключно метод GET, для запобігання будь-яких дій при автоматизованих запитах.

Тим не менш, є причини чому POST використовується навіть для ідемпотентних запитів, особливо у випадках коли запит використовує не-ASCII символи або дуже довгий, через обмеження на URL.

Примітки[ред.ред. код]

  1. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Процитовано 2014-07-24. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.» 
  2. Berners-Lee, Tim; Connolly, Dan (22 September 1995). Hypertext Markup Language - 2.0 - Forms. World Wide Web Consortium. Процитовано 15 January 2011. 
  3. Forms in HTML documents.