HTTP definește diferite moduri de a interacționa cu serverul, iar există 4 metode de bază, și anume GET, POST, PUT și DELETE. Numele complet al URL-ului este un descriptor de resurse, îl putem gândi astfel: o adresă URL, este folosită pentru a descrie o resursă dintr-o rețea, iar GET, POST, PUT, DELETE în HTTP corespunde celor patru operații de verificare, modificare, adăugare și ștergere a acestei resurse. În acest moment, ar trebui să ai o înțelegere generală: GET este folosit în general pentru a obține/interoga informații despre resurse, în timp ce POST este folosit în general pentru a actualiza informațiile despre resurse.
1. Conform specificației HTTP, GET este folosit pentru recuperarea informațiilor și ar trebui să fie sigur și idempotent.
(1). Așa-numita securitate înseamnă că operațiunea este folosită pentru a obține informații, nu pentru a o modifica. Cu alte cuvinte, cererile GET nu ar trebui, în general, să aibă efecte secundare. Cu alte cuvinte, obține doar informații despre resurse, la fel ca interogarea bazei de date, și nu va modifica, adăuga date și nu va afecta starea resursei.
* Notă: Sensul de securitate aici se referă doar la informații nemodificate.
(2). idempotent înseamnă că mai multe cereri către același URL ar trebui să returneze același rezultat.
Totuși, în practică, cele două reglementări de mai sus nu sunt atât de stricte. Exemple de citare a articolelor altora: De exemplu, prima pagină a unui site de știri este actualizată constant. Deși a doua cerere returnează un lot diferit de știri, operațiunea este totuși considerată sigură și idempotentă deoarece returnează întotdeauna știrile curente. În esență, dacă scopul este ca atunci când un utilizator deschide un link, să poată fi sigur că resursa nu a fost schimbată din punctul său de vedere.
2. Conform specificației HTTP, POST reprezintă o cerere care poate modifica o resursă pe server. Continuând să citez exemplul de mai sus: Știri statice Luați site-ul ca exemplu, cititorii ar trebui să posteze propriile comentarii la știri, deoarece resursele site-ului sunt diferite după ce comentariul este trimis sau resursele sunt modificate.
Cele de mai sus discută aproximativ unele dintre principiile GET și POST din specificația HTTP. Totuși, mulți oameni nu respectă specificația HTTP atunci când fac efectiv acest lucru, ceea ce poate duce la multe motive pentru această problemă, cum ar fi:
1. Mulți oameni folosesc GET pentru a actualiza resursele pentru că trebuie să meargă la FORM pentru a folosi POST, ceea ce poate fi puțin problematic.
2. Operațiunea de adăugare, ștergere, modificare și verificare a resurselor poate fi realizată efectiv prin GET/POST, fără a fi nevoie de utilizarea PUT și DELETE.
3. O altă problemă este că designerii timpurii de framework-uri Web MVC nu au tratat și proiectat conștient URL-urile ca resurse abstracte, astfel că o problemă serioasă este că cadrul tradițional Web MVC suportă practic doar două metode HTTP, GET și POST, dar nu suportă metodele PUT și DELETE.
* O scurtă explicație a MVC: MVC a existat inițial în programul Desktop, M se referă la modelul de date, V la interfața utilizatorului, iar C la controler. Scopul utilizării MVC este de a separa codul de implementare al lui M și V, astfel încât același program să poată folosi reprezentări diferite.
Cele 3 puncte de mai sus descriu de obicei vechiul stil (fără respectarea strictă a specificației HTTP), iar odată cu dezvoltarea arhitecturii, există acum REST (Representational State Transfer), un stil nou care suportă specificația HTTP.
După ce vorbim despre problema principală, să analizăm diferența dintre GET și POST față de fenomenul de suprafață:
1. Datele cererii GET vor fi atașate URL-ului (adică datele sunt plasate în antetul protocolului HTTP), iar ? Desparte URL-ul și transmite datele, iar parametrii sunt conectați prin &, de exemplu: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Dacă datele sunt litere/numere englezești, trimite-le așa cum sunt, dacă este un spațiu, convertește-le în +, dacă sunt chinezești/alte caractere, apoi criptează direct șirul cu BASE64 pentru a obține un eșantion precum: %E4%BD%A0%E5%A5%BD, unde XX în %XX este ASCII-ul reprezentat de simbolul hexazecial.
POST plasează datele trimise în corpul pachetului HTTP.
2. "Datele maxime transmise de metoda GET pot fi doar 1024 octeți, teoretic nu există limită pentru POST, iar o cantitate mare de date poate fi transferată, până la 80KB în IIS4 și 100KB în IIS5??!
Propoziția de mai sus este redirecționată din alte articole, de fapt, este greșit și inexact să spui asta:
(1). În primul rând, "datele trimise prin metoda GET pot avea cel mult 1024 octeți", deoarece GET trimite date prin URL, deci cantitatea de date care poate fi trimisă de GET este direct legată de lungimea URL-ului. De fapt, nu există o limită superioară de parametri pentru URL-uri, iar specificația protocolului HTTP nu limitează lungimea URL-urilor. Această limită este o limitare impusă de un anumit browser și server. Limita IE privind lungimea URL-ului este de 2083 octeți (2K+35). Pentru alte browsere precum Netscape, Firefox etc., nu există o limită teoretică de lungime, iar limita depinde de suportul sistemului de operare.
Reține că acest lucru limitează întreaga lungime a URL-ului, nu doar valoarea parametrului, lungimea datelor. [Vezi Ref. 5]
(2). Teoretic, POST nu are limită de dimensiune, iar specificația protocolului HTTP nu are o limită de dimensiune, iar este inexact să spui că "există o limită de dimensiune de 80K/100K pentru datele POST", nu există o limită pentru datele POST, iar puterea de procesare a handlerului serverului joacă un rol limitativ.
Pentru programele ASP, obiectul Request are o limită de lungime de 100K la procesarea fiecărui câmp de formular. Dar cu Request.BinaryRead nu există o astfel de limitare.
Ulterior, pentru IIS 6.0, Microsoft a crescut restricțiile din motive de securitate. De asemenea, trebuie să acordăm atenție la:
1). IIS 6.0 are implicit un maxim de 200 KB de date ASP POST, iar limita este de 100 KB per câmp de formular.
2). Dimensiunea implicită a fișierelor de încărcare din IIS 6.0 este de 4MB.
3). IIS 6.0 are implicit un antet maxim de cerere de 16KB.
Aceste limitări nu erau disponibile înainte de IIS 6.0. [Vezi Ref. 5]
Deci valorile de mai sus 80K și 100K pot fi doar valorile implicite (notă: nu am confirmat încă parametrii IIS4 și IIS5), dar cu siguranță le poți seta singur. Deoarece valorile implicite pentru acești parametri diferă în fiecare versiune a IIS, vă rugăm să consultați documentul relevant de configurare IIS pentru detalii.
3. În ASP, serverul folosește Request.QueryString pentru a obține parametrul de cerere GET și Request.Form pentru a obține parametrul de cerere POST. În JSP, folosește request.getParameter(\"XXXX\") pentru a o obține, deși există și o metodă request.getQueryString() în jsp, dar este mai dificilă de folosit, de exemplu: trimite un test.jsp?name=hyddd&password=hyddd și folosește request.getQueryString() pentru a obține :name= hyddd&password=hyddd。 În PHP, poți folosi $_GET și $_POST pentru a obține date de la GET și POST, respectiv, în timp ce $_REQUEST poate obține date atât din cereri GET, cât și POST. Este demn de menționat că există pericole ascunse în folosirea cererii în JSP și a _REQUEST de dolari în PHP, care vor fi rezumate într-un articol data viitoare.
4.POST este mai sigur decât GET. Notă: Securitatea menționată aici nu este același concept cu "securitatea" menționată în GET de mai sus. De exemplu, dacă trimiți date prin GET, numele tău de utilizator și parola vor apărea în text clar pe adresa URL, deoarece (1) pagina de autentificare poate fi stocată în cache de browser, (2) alții vor vedea istoricul browserului, astfel încât alții să poată obține contul și parola ta atac de falsificare.
În concluzie, Get este o cerere de a solicita date de la server, în timp ce Post este o cerere de a trimite date către server, în FORM, Method este implicit "GET", în esență, GET și POST sunt doar mecanisme diferite de trimitere, nu se ia și nu se trimite!
|
Postat pe 06.12.2014 10:54:55
|
|
|
Postat pe 07.12.2014 17:24:18
