HTTP визначає різні способи взаємодії з сервером, і існує 4 основні методи: GET, POST, PUT і DELETE. Повна назва URL — це дескриптор ресурсу, його можна уявити так: URL-адреса, яка використовується для опису ресурсу в мережі, а GET, POST, PUT, DELETE у HTTP відповідає чотирьом операціям: перевірка, модифікація, додавання та видалення цього ресурсу. На цьому етапі ви маєте загальне розуміння: GET зазвичай використовується для отримання/запиту інформації про ресурси, а POST — для оновлення інформації про ресурси.
1. Відповідно до специфікації HTTP, GET використовується для отримання інформації і має бути безпечним та ідемпотентним.
(1). Так звана безпека означає, що операція використовується для отримання інформації, а не для її зміни. Іншими словами, запити на GET зазвичай не повинні мати побічних ефектів. Тобто, він отримує лише інформацію про ресурси, як і запит до бази даних, і не змінює, не додає даних і не впливає на стан ресурсу.
* Примітка: Значення безпеки тут стосується лише немодифікованої інформації.
(2). Ідемпотентний означає, що кілька запитів на одну й ту ж адресу мають повертати однаковий результат.
Однак на практиці ці два правила не є такими суворими. Приклади цитування чужих статей: Наприклад, головна сторінка новинного сайту постійно оновлюється. Хоча другий запит повертає іншу партію новин, операція все одно вважається безпечною та ідемпотентною, оскільки завжди повертає актуальні новини. По суті, якщо мета полягає в тому, щоб користувач відкривав посилання, він міг бути впевнений, що ресурс не був змінений з його точки зору.
2. Згідно зі специфікацією HTTP, POST — це запит, який може змінювати ресурс на сервері. Продовжуючи цитувати наведений вище приклад: Статичні новини. Візьмемо сайт як приклад: читачі повинні залишати власні коментарі до новин, бо ресурси сайту змінюються після подання коментаря або змін ресурсів.
Вищезазначене приблизно розглядає деякі принципи GET і POST у специфікації HTTP. Однак багато людей не дотримуються HTTP-специфікації під час фактичного виконання, що може призвести до багатьох причин цієї проблеми, таких як:
1. Багато людей використовують GET для оновлення ресурсів, бо їм потрібно перейти до FORM, щоб використовувати POST, що може бути трохи клопітним.
2. Операцію додавання, видалення, зміни та перевірки ресурсів можна фактично виконати через GET/POST без необхідності використовувати PUT і DELETE.
3. Ще одна — ранні розробники фреймворків Web MVC не свідомо розглядали та не проектували URL як абстрактні ресурси, тому серйозною проблемою є те, що традиційний фреймворк Web MVC фактично підтримує лише два HTTP-методи — GET і POST, але не підтримує методи PUT і DELETE.
* Коротке пояснення MVC: MVC спочатку існував у програмі Desktop, M — модель даних, V — інтерфейс користувача, C — контролер. Мета використання MVC — розділити код реалізації M і V, щоб одна й та сама програма могла використовувати різні представлення.
Вищезазначені 3 пункти зазвичай описують старий стиль (без суворого дотримання HTTP-специфікації), а з розвитком архітектури з'явився REST (Representational State Transfer), новий стиль, що підтримує специфікацію HTTP.
Після обговорення основної проблеми давайте розглянемо різницю між GET і POST за поверхневим явищем:
1. Дані запиту GET будуть прикріплені до URL (тобто дані розміщені в заголовку протоколу HTTP), а ? Розділіть URL і передайте дані, і параметри з'єднуються за допомогою &, наприклад: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Якщо дані — англійські літери/цифри, надішліть їх як є, якщо це пробіл — конвертуйте у +, якщо це китайські або інші символи, потім безпосередньо шифруйте рядок BASE64, щоб отримати зразок, наприклад: %E4%BD%A0%E5%A5%BD, де XX у %XX — це ASCII, представлений символом у шістнадцятковій формі.
POST розміщує подані дані у тіло пакета HTTP-пакета.
2. «Максимальна кількість даних, поданих методом GET, може становити лише 1024 байти, теоретично обмеження для POST немає, і можна передавати велику кількість даних — до 80 КБ у IIS4 і 100 КБ у IIS5??!
Вищенаведене речення перенаправлене з інших статей, насправді неправильно і неточно так казати:
(1). По-перше, «дані, подані методом GET, можуть бути максимум 1024 байтами», оскільки GET надсилає дані через URL, тому обсяг даних, які може бути поданий GET, безпосередньо пов'язаний із довжиною URL. Насправді для URL немає верхнього обмеження параметрів, і специфікація протоколу HTTP не обмежує довжину URL. Це обмеження є обмеженням, накладеним конкретним браузером і сервером. Обмеження довжини URL у IE становить 2083 байти (2K+35). Для інших браузерів, таких як Netscape, Firefox тощо, теоретичного обмеження довжини немає, і воно залежить від підтримки операційної системи.
Зверніть увагу, що це обмежує всю довжину URL, а не лише довжину даних значення параметрів. [Див. посилання 5]
(2). Теоретично POST не має обмеження за розміром, і специфікація протоколу HTTP не має обмеження розміру, і неточно казати, що «існує обмеження розміру 80K/100K для POST-даних», і немає обмежень для даних POST, і обмежувальну роль відіграє обчислювальна потужність обробника сервера.
Для ASP-програм об'єкт Request має обмеження довжини даних 100K при обробці кожного поля форми. Але з Request.BinaryRead такого обмеження немає.
Крім цього, для IIS 6.0 Microsoft посилила обмеження з міркувань безпеки. Також потрібно звернути увагу на:
1). IIS 6.0 за замовчуванням має максимум 200 КБ даних ASP POST, а ліміт — 100 КБ на кожне поле форми.
2). Стандартний розмір файлів для завантаження IIS 6.0 становить 4 МБ.
3). IIS 6.0 за замовчуванням має максимальний заголовок запиту 16 КБ.
Ці обмеження не були доступні до IIS 6.0. [Див. посилання 5]
Тож ці 80K і 100K можуть бути просто значеннями за замовчуванням (примітка: я ще не підтвердив параметри IIS4 та IIS5), але ви точно можете встановити їх самостійно. Оскільки значення за замовчуванням для цих параметрів відрізняються в кожній версії IIS, будь ласка, зверніться до відповідного конфігураційного документа IIS для деталей.
3. В ASP сервер використовує Request.QueryString для отримання параметра запиту GET і Request.Form для отримання параметра запиту POST. У JSP використовуйте request.getParameter(\"XXXX\") для отримання, хоча в jsp також є метод request.getQueryString(), але він складніший у використанні, наприклад: надіслати test.jsp?name=hyddd&password=hyddd і використати request.getQueryString() для отримання :name= hyddd&password=hyddd。 У PHP ви можете використовувати $_GET і $_POST для отримання даних з GET і POST відповідно, тоді як $_REQUEST може отримати дані як із GET, так і з POST запитів. Варто зазначити, що існують приховані небезпеки використання запиту в JSP і $_REQUEST у PHP, що буде підсумовано в статті наступного разу.
4.POST безпечніший за GET. Примітка: Згаданий тут цінний акт не є тією ж концепцією, що й «безпека», згадана у GET вище. Наприклад, якщо ви надсилаєте дані через GET, ваше ім'я користувача та пароль відображатимуться у відкритому вигляді на URL, оскільки (1) сторінка входу може бути кешована браузером, (2) інші переглядатимуть історію браузера, щоб інші могли отримати ваш акаунт і пароль Атака на підробку.
Підсумовуючи, Get — це запит на запит даних із сервера, тоді як Post — запит на надсилання даних на сервер, у FORM метод за замовчуванням ставить «GET», тобто GET і POST — це просто різні механізми відправлення, а не один із них бере і надсилає!
|
Опубліковано 06.12.2014 10:54:55
|
|
|
Опубліковано 07.12.2014 17:24:18
