HTTP дефинира различни начини за взаимодействие със сървъра, като има 4 основни метода, а именно GET, POST, PUT и DELETE. Пълното име на URL е дескриптор на ресурс, можем да го видим така: URL адрес, който се използва за описание на ресурс в мрежа, а GET, POST, PUT, DELETE в HTTP съответства на четирите операции – проверка, модифициране, добавяне и изтриване на този ресурс. На този етап трябва да имате общо разбиране, че GET обикновено се използва за получаване/търсене на информация за ресурси, докато POST обикновено се използва за актуализиране на информация.
1. Според HTTP спецификацията, GET се използва за извличане на информация и трябва да бъде сигурен и идемпотентен.
(1). Т.нар. сигурност означава, че операцията се използва за получаване на информация, а не за нейно модифициране. С други думи, заявките за GET обикновено не трябва да имат странични ефекти. Тоест, той получава само информация за ресурси, подобно на заявката в базата данни, и няма да променя, добавя данни или да влияе на състоянието на ресурса.
* Забележка: Значението на сигурност тук се отнася само до немодифицирана информация.
(2). Идемпотентно означава, че множество заявки към един и същ URL трябва да връщат един и същ резултат.
Въпреки това, на практика горните две регулации не са толкова строги. Примери за цитиране на статии на други хора: Например, началната страница на новинарски сайт се обновява постоянно. Въпреки че втората заявка връща различна партида новини, операцията все пак се счита за безопасна и идемпотентна, защото винаги връща актуалните новини. По същество, ако целта е когато потребителят отвори връзка, той да бъде сигурен, че ресурсът не е бил променен от неговата гледна точка.
2. Според HTTP спецификацията, POST представлява заявка, която може да модифицира ресурс на сървъра. Продължавам да цитирам горния пример: Все още новини Вземете уебсайта като пример – читателите трябва да публикуват свои коментари към новината, защото ресурсите на сайта са различни след като коментарът е подаден или ресурсите са променени.
Горното приблизително разглежда някои от принципите на GET и POST в HTTP спецификацията. Въпреки това, много хора не следват HTTP спецификацията при реалното изпълнение, което може да доведе до много причини за този проблем, като например:
1. Много хора използват GET, за да актуализират ресурси, защото трябва да преминат към FORM, за да използват POST, което може да е малко проблемно.
2. Операцията по добавяне, изтриване, модифициране и проверка на ресурси може реално да се извърши чрез GET/POST, без необходимост от използване на PUT и DELETE.
3. Друг е, че ранните дизайнери на уеб MVC фреймуърци не са третирали съзнателно и проектирали URL адресите като абстрактни ресурси, така че сериозен проблем е, че традиционната уеб 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, и може да се прехвърля голямо количество данни, до 80KB в IIS4 и 100KB в IIS5"??!
Горното изречение е пренасочено от други статии, всъщност е грешно и неточно да се казва това:
(1). Първо, "данните, подадени от метода GET, могат да бъдат най-много 1024 байта", защото GET подава данни чрез URL, така че количеството данни, което може да бъде подадено чрез GET, е пряко свързано с дължината на URL адреса. Всъщност няма горна граница на параметрите за URL адресите, а спецификацията на HTTP протокола не ограничава дължината на URL адресите. Това ограничение е наложено от конкретен браузър и сървър. Ограничението на IE за дължина на URL адреса е 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 KB ASP POST данни, а лимитът е 100 KB на поле за форма.
2). Стандартният размер на файловете за качване в IIS 6.0 е 4MB.
3). IIS 6.0 по подразбиране има максимален заглавие за заявка от 16KB.
Тези ограничения не бяха налични преди IIS 6.0. [Виж Реф. 5]
Така че горните 80K и 100K може да са просто стандартните стойности (забележка: все още не съм потвърдил параметрите на IIS4 и IIS5), но определено можете да ги зададете сами. Тъй като стойностите по подразбиране за тези параметри са различни във всяка версия на IIS, моля, вижте съответния конфигурационен документ на IIS за подробности.
3. В ASP сървърът използва Request.QueryString, за да получи параметъра GET заявка, и Request.Form за получаване на параметъра POST заявка. В JSP използвайте request.getParameter(\"XXXX\") за получаване, въпреки че има и метод request.getQueryString() в jsp, но е по-труден за използване, например: изпратете 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 Method по подразбиране е "GET", което по същество GET и POST са просто различни механизми за изпращане, не се взима и изпраща един!
|
Публикувано в 6.12.2014 г. 10:54:55 ч.
|
|
|
Публикувано в 7.12.2014 г. 17:24:18 ч.
