HTTP POST solicită furnizarea de date suplimentare de la client (browser) către serverul din corpul mesajului. In contrast, OBȚINE cererile includ toate datele necesare în URL. Formularele în HTML pot utiliza oricare dintre metode prin specificarea Metoda = "POST" sau Metoda = "GET" (implicit) în element. Metoda specificată determină modul în care sunt trimise datele de pe server. Atunci când metoda este GET, toate datele de formular sunt codificate în URL-ul atașat la acțiune URL ca parametru șir de interogare. Cu POST, datele formularului apar în corpul mesajului din cererea HTTP.
OBȚINE | POST | |
---|---|---|
Istorie | Parametrii rămân în istoricul browserului deoarece fac parte din URL | Parametrii nu sunt salvați în istoricul browserului. |
marcată | Poate fi marcată. | Nu poate fi marcată. |
BACK butonul / retransmite comportamentul | Cererile GET sunt re-executate, dar nu pot fi retransmise pe server dacă HTML-ul este stocat în cache-ul browserului. | De obicei, browserul alertează utilizatorul că datele trebuie să fie retransmise. |
Tipul de codare (atributul enctype) | application / x-www-form-urlencoded | multipart / form-data sau aplicație / x-www-form-urlencoded Utilizați codificarea multipart pentru datele binare. |
Parametrii | poate trimite, dar datele parametrilor se limitează la ceea ce putem include în linia de solicitare (URL). Cel mai sigur este să utilizați mai puțin de 2 kilometri de parametri, unele servere ocupă până la 64 kilograme | Poate trimite parametri, inclusiv încărcarea fișierelor, la server. |
Tocat | Ușor de hack pentru copiii scripturi | Mai greu de hacking |
Restricții la tipul de date pentru formulare | Da, sunt permise numai caracterele ASCII. | Fara restrictii. Sunt permise și date binare. |
Securitate | GET este mai puțin sigur în comparație cu POST, deoarece datele trimise fac parte din URL. Așa că este salvat în istoricul browserului și în jurnalele de server în textul plaintext. | POST este puțin mai sigur decât GET, deoarece parametrii nu sunt stocați în istoricul browserului sau în jurnalele serverului web. |
Restricții privind lungimea datelor formularului | Da, deoarece datele formularului sunt în URL și lungimea URL-ului este restricționată. O limită sigură de lungime a adresei URL este adesea de 2048 de caractere, dar variază de browser și de serverul web. | Fara restrictii |
Usability | Metoda GET nu trebuie utilizată atunci când trimiteți parole sau alte informații sensibile. | Metoda POST utilizată la trimiterea parolelor sau a altor informații sensibile. |
Vizibilitate | Metoda GET este vizibilă pentru toată lumea (va fi afișată în bara de adrese a browserului) și are limite pentru cantitatea de informații pe care trebuie să o trimită. | Variabilele metodei POST nu sunt afișate în adresa URL. |
În cache | Poate fi stocat în cache | Nu este memorat în cache |
Diferența fundamentală între Method = "GET" și Method = "POST" este că acestea corespund diferite cereri HTTP, așa cum este definită în specificațiile HTTP. Procesul de trimitere pentru ambele metode începe în același mod - un set de date de formă este construit de browser și apoi codificat într-o manieră specificată de enctype atribut. Pentru Method = "POST enctype atributul poate fi multipart / form-data sau application / x-www-form-urlencoded, întrucât pentru Method = "GET", numai application / x-www-form-urlencoded este permis. Acest set de date de formă este apoi transmis către server.
Pentru trimiterea formularului cu METHOD = "GET", browserul construiește o adresă URL luând valoarea lui acțiune atribut, adăugând a ? la acesta, apoi adăugând setul de date pentru formular (codificat utilizând tipul de conținut / aplicație / x-www-form-urlencoded). Browserul procesează apoi această adresă URL ca și cum ar fi urmărit un link (sau ca și cum utilizatorul ar fi introdus direct adresa URL). Browserul împarte URL-ul în părți și recunoaște o gazdă, apoi trimite gazdei respective o solicitare GET cu restul adresei URL ca argument. Serverul o ia de acolo. Rețineți că acest proces înseamnă că datele formularului sunt restricționate la codurile ASCII. O atenție deosebită trebuie acordată pentru codificarea și decodificarea altor tipuri de caractere atunci când acestea sunt transmise prin adresa URL în format ASCII.
Trimiterea unui formular cu METHOD = "POST" determină trimiterea unei cereri POST, folosind valoarea lui acțiune atribut și un mesaj creat în funcție de tipul de conținut specificat de enctype atribut.
Deoarece datele formularului sunt trimise ca parte a adresei URL când OBȚINE este folosit --
În principiu, prelucrarea datelor din formularul depus depinde de faptul că este trimis cu Method = "GET" sau Method = "POST". Dat fiind că datele sunt codificate în moduri diferite, sunt necesare mecanisme de decodificare diferite. Astfel, în general, modificarea metodei poate necesita o modificare a scriptului care procesează prezentarea. De exemplu, atunci când utilizați interfața CGI, scriptul primește datele într-o variabilă de mediu (QUERYSTRING) atunci când OBȚINE este folosit. Dar cand POST , datele de formular sunt transferate în fluxul de intrare standard (stdin), iar numărul de octeți de citit este dat de antetul de lungime a conținutului.
GET se recomandă atunci când trimiteți formulare "idempotent" - cele care nu "modifică semnificativ starea lumii". Cu alte cuvinte, forme care implică doar interogări baze de date. O altă perspectivă este că mai multe interogări idempotent vor avea același efect ca o singură interogare. Dacă sunt implicate actualizări ale bazei de date sau alte acțiuni, cum ar fi declanșarea mesajelor e-mail, se recomandă utilizarea POST.
Din blogul dezvoltatorului Dropbox:
un browser nu știe exact ce face un anumit formular HTML, dar dacă formularul este trimis prin HTTP GET, browserul știe că este în siguranță să reîncercați automat trimiterea dacă există o eroare de rețea. În cazul formularelor care utilizează HTTP POST, este posibil ca reîncercarea să nu fie sigură, astfel că browserul cere mai întâi utilizatorului confirmarea.
O solicitare "GET" este de multe ori disponibilă în cache, în timp ce o solicitare "POST" poate fi dificilă. Pentru sistemele de interogare acest lucru poate avea un impact considerabil asupra eficienței, mai ales dacă șirurile de interogare sunt simple, deoarece cache-urile ar putea servi cele mai frecvente interogări.
În anumite cazuri, folosind POST se recomandă chiar și pentru interogările idempotent:
Actualizat 15 mai 2015: Mai exact, atunci când se utilizează HTTPS (HTTP peste TLS / SSL), POST oferă mai multă securitate decât GET?
Aceasta este o întrebare interesantă. Spuneți că faceți o solicitare GET către o pagină Web:
GET https://www.example.com/login.php?user=mickey&passwd=mini
Presupunând că conexiunea la Internet este monitorizată, ce informații despre această solicitare vor fi disponibile pentru snooper? Dacă se utilizează în schimb POST și datele utilizator și passwd sunt incluse în variabilele POST, aceasta va fi mai sigură în cazul conexiunilor HTTPS?
Raspunsul este nu. Dacă faceți o astfel de solicitare GET, numai următorii informații vor fi cunoscute de atacatorul care vă monitorizează traficul web:
Partea de cale a adresei URL - adică pagina actuală solicitată, precum și parametrii șirului de interogare - sunt protejați (criptate) în timp ce aceștia sunt "peste fir", adică în tranzit în drum spre serverul de destinație. Situația este exact aceeași pentru solicitările POST.
Desigur, serverele web tind să înregistreze întreaga adresă URL în text simplu în jurnalele lor de acces; trimiterea de informații sensibile prin GET nu este o idee bună. Acest lucru se aplică indiferent dacă se utilizează HTTP sau HTTPS.