GET vs. POST
Share
HTTP POST запитує подати додаткові дані від клієнта (браузера) на сервер в тілі повідомлення. У контрасті, ЗАРАЗ запити включають усі необхідні дані в URL-адресу. Форми в HTML можуть використовувати будь-який метод, вказавши метод = "POST" або метод = "Отримати" (за замовчуванням) у елемент. Зазначений метод визначає, як дані форми подаються на сервер. Коли метод GET, всі дані форми кодуються в URL-адресу, додану до дії URL як параметри рядка запиту. З POST дані форми відображаються в тілі повідомлення запиту HTTP.
Порівняльна діаграма
| ЗАРАЗ | POST | |
|---|---|---|
| Історія | Параметри залишаються в історії браузера, оскільки вони є частиною URL-адреси | Параметри не зберігаються в історії браузера. |
| Закладка | Можна зробити закладку. | Неможливо встановити закладки. |
| Кнопка НАЗАД / повторне подання | GET-запити повторно виконуються, але їх не можна повторно подавати на сервер, якщо HTML зберігається в кеші браузера. | Зазвичай браузер попереджає користувача про те, що дані потрібно буде повторно подати. |
| Тип кодування (атрибут enctype) | додаток / x-www-form-urlencoded | багаточастинні / форма-дані або додаток / x-www-form-urlencoded Використовуйте багаточастинне кодування для бінарних даних. |
| Параметри | може надсилати, але дані параметрів обмежені тим, що ми можемо вставити у рядок запиту (URL). Найбезпечніше використовувати параметри менше ніж 2 К, деякі сервери обробляють до 64 Кб | Може надіслати параметри, включаючи завантаження файлів, на сервер. |
| Зламали | Простіше зламати для дітей сценарію | Складніше зламати |
| Обмеження щодо типу даних форми | Так, дозволено використовувати лише символи ASCII. | Без обмежень. Бінарні дані також дозволені. |
| Безпека | GET менш безпечний порівняно з POST, оскільки дані, що надсилаються, є частиною URL-адреси. Таким чином, це зберігається в історії браузера та журналах сервера в простому тексті. | POST трохи безпечніший ніж GET, оскільки параметри не зберігаються в історії браузера або в журналах веб-сервера. |
| Обмеження щодо довжини даних форми | Так, оскільки дані форми є в URL-адресі, а довжина URL-адреси обмежена. Безпечна межа довжини URL-адреси часто 2048 символів, але залежить від браузера та веб-сервера. | Без обмежень |
| Корисність | Метод GET не слід використовувати при надсиланні паролів або іншої конфіденційної інформації. | Метод POST, який використовується при надсиланні паролів або іншої конфіденційної інформації. |
| Видимість | Метод GET видимий для всіх (він відображатиметься в адресному рядку веб-переглядача) і має обмеження щодо кількості інформації для надсилання. | Змінні методу POST не відображаються в URL-адресі. |
| Кешування | Можна кешувати | Не кешовано |
Зміст: GET vs POST
- 1 Відмінності у поданні форми
- 1.1 плюси і мінуси
- 2 Відмінності в серверній обробці
- 3 Рекомендоване використання
- 4 Як щодо HTTPS?
- 5 Список літератури
Відмінності у поданні форми
Принципова різниця між METHOD = "Отримати" і METHOD = "POST" це те, що вони відповідають різні HTTP-запити, як визначено в специфікаціях HTTP. Процес подання обох методів починається однаково - набір даних форми формується браузером і потім кодується у спосіб, визначений ентетип атрибут. Для METHOD = "POST то ентетип атрибут може бути багаточастинні / форми-дані або додаток / x-www-form-urlencoded, тоді як для METHOD = "Отримати", тільки додаток / x-www-form-urlencoded дозволено. Потім цей набір даних форми передається серверу.
Для подання форми з METHOD = "GET" браузер будує URL-адресу, приймаючи значення дії атрибут, додаючи а ? до нього, потім додаючи набір даних форми (кодується за допомогою типу вмісту application / x-www-form-urlencoded type). Потім браузер обробляє цю URL-адресу, ніби переходячи за посиланням (або як якщо б користувач ввів URL-адресу безпосередньо). Веб-переглядач розділяє URL-адресу на частини і розпізнає хост, а потім надсилає цьому хосту GET-запит з рештою URL-адреси в якості аргументу. Сервер приймає його звідти. Зауважте, що цей процес означає, що дані форми обмежені кодами ASCII. Слід бути особливо обережним для кодування та декодування інших типів символів при передачі їх через URL-адресу у форматі ASCII.
Подання форми з METHOD = "POST" викликає надсилання запиту POST, використовуючи значення дії атрибут та повідомлення, створене відповідно до типу вмісту, визначеного ентетип атрибут.
Плюси і мінуси
Оскільки дані форми надсилаються як частина URL коли ЗАРАЗ використовується --
- Дані форми обмежені кодами ASCII. Слід бути особливо обережним для кодування та декодування інших типів символів при передачі їх через URL-адресу у форматі ASCII. З іншого боку, всі бінарні дані, зображення та інші файли можуть бути передані через METHOD = "POST"
- Усі заповнені дані форми видно в URL-адресі. Крім того, він також зберігається в історії / журналах веб-переглядачів для веб-переглядача. Ці питання викликають ЗАРАЗ менш безпечний.
- Однак однією з переваг даних форми, що надсилаються як частина URL-адреси, є те, що можна створювати закладки URL-адрес і безпосередньо використовувати їх і повністю обходити процес заповнення форми..
- Існує обмеження щодо кількості даних форми, які можна надсилати, оскільки довжина URL-адреси обмежена.
- Діти сценаріїв можуть легше розкрити вразливості в системі, щоб зламати її. Наприклад, Citibank зламали, змінивши номери рахунків у рядку URL.[1] Звичайно, досвідчені хакери або веб-розробники можуть виявити такі вразливості, навіть якщо використовується POST; це просто трохи важче. Загалом, сервер повинен підозрювати будь-які дані, надіслані клієнтом, і захищати від небезпечних прямих посилань на об’єкти.
Відмінності в серверній обробці
В принципі, обробка поданих даних форми залежить від того, чи надсилаються вони METHOD = "Отримати" або METHOD = "POST". Оскільки дані кодуються по-різному, потрібні різні механізми декодування. Таким чином, загалом кажучи, зміна способу може вимагати зміни сценарію, який обробляє подання. Наприклад, при використанні інтерфейсу CGI сценарій отримує дані в змінній середовища (QUERYSTRING), коли ЗАРАЗ використовується. Але коли POST використовується, дані форми передаються у стандартному потоці введення (stdin), а кількість байтів, які потрібно прочитати, задається заголовком довжини вмісту.
Рекомендоване використання
GET рекомендується подавати "ідентичні" форми - ті, які не "суттєво змінюють стан світу". Іншими словами, форми, які включають лише запити до бази даних. Інша перспектива полягає в тому, що кілька ідентифікованих запитів матимуть такий же ефект, як і один запит. Якщо задіяні оновлення бази даних або інші дії, такі як запуск електронних листів, рекомендується використовувати POST.
З блогу розробників Dropbox:
веб-переглядач не точно знає, що робить певна форма HTML, але якщо форма подається через HTTP GET, браузер знає, що безпечно автоматично повторити подання, якщо є мережна помилка. Для форм, які використовують HTTP POST, можливо, це не є безпечним для повторної спроби, тому браузер спочатку запитує у користувача підтвердження.
Запит "GET" часто кешується, тоді як запит "POST" навряд чи може бути. Для систем запитів це може мати значний вплив на ефективність, особливо якщо рядки запитів прості, оскільки кеші можуть обслуговувати найчастіші запити.
У певних випадках використовують POST рекомендується навіть для ідентичних запитів:
- Якщо дані форми містять символи, що не належать до ASCII (наприклад, наголошені символи), потім METHOD = "Отримати" в принципі не застосовується, хоча це може працювати на практиці (в основному для ISO латинських символів 1).
- Якщо набір даних форми великий - скажімо, сотні персонажів - значить METHOD = "Отримати" може спричинити практичні проблеми з реалізаціями, які не в змозі обробити такі довгі URL-адреси.
- Ви можете уникнути METHOD = "Отримати" щоб зробити його менш помітним для користувачів, як працює форма, особливо для того, щоб зробити "приховані" поля (INPUT TYPE = "HIDDEN") більш прихованими, не з'являючись у URL-адресі. Але навіть якщо ви використовуєте приховані поля з METHOD = "POST", вони все ще з’являться у вихідному коді HTML.
Як щодо HTTPS?
Оновлено 15 травня 2015 року. Зокрема, при використанні HTTPS (HTTP через TLS / SSL) POST пропонує більш безпеку, ніж GET?
Це цікаве питання. Скажіть, ви робите запит GET на веб-сторінку:
Отримайте https://www.example.com/login.php?user=mickey&passwd=mini
Якщо припустити, що підключення до Інтернету контролюється, яка інформація про цей запит буде доступна для снайпера? Якщо замість цього використовується POST, а дані користувача та passwd включені до змінних POST, чи буде це більш безпечно у випадку з'єднань HTTPS?
Відповідь - ні. Якщо ви робите такий запит GET, зловмиснику буде відома лише така інформація, яка контролює ваш веб-трафік:
- Те, що ви встановили HTTPS-з'єднання
- Ім'я хоста - www.example.com
- Загальна тривалість запиту
- Тривалість відповіді
Частина шляху URL-адреси - тобто фактична запитувана сторінка, а також параметри рядка запиту - захищені (зашифровані), поки вони знаходяться "по дроту", тобто під час руху на шляху до цільового сервера. Ситуація точно така ж і для запитів POST.
Звичайно, веб-сервери, як правило, реєструють всю URL-адресу в простому тексті у своїх журналах доступу; тому надсилання конфіденційної інформації через GET не є хорошою ідеєю. Це застосовується незалежно від того, використовується HTTP або HTTPS.
Список літератури
- Вікіпедія: POST (HTTP)
- Методи запиту HTTP
- Повідомлення HTTP - W3.org
- HTTP Get - W3.org
- Чи HTTPS приховує URL-адреси, до яких звертається? - Обмін стеками
