GET vs. POST

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.

Diagramă de comparație

GET comparativ cu tabela de comparație POST
OBȚINEPOST
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

Conținut: GET vs POST

  • 1 Diferențe în transmiterea formularului
    • 1.1 Pro și contra
  • 2 Diferențe în procesarea pe server
  • 3 Utilizare recomandată
  • 4 Ce se întâmplă cu HTTPS?
  • 5 Referințe

Diferențe în transmiterea formularului

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.

Argumente pro şi contra

Deoarece datele formularului sunt trimise ca parte a adresei URL când OBȚINE este folosit --

  • 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. Pe de altă parte, pot fi trimise date binare, imagini și alte fișiere Method = "POST"
  • Toate datele formularului completate sunt vizibile în adresa URL. Mai mult, este stocat și în istoricul / jurnalele de navigare ale browserului pentru utilizator. Aceste probleme fac OBȚINE mai puțin sigură.
  • Cu toate acestea, un avantaj al formularului de date care este trimis ca parte a adresei URL este că se pot marca marcajul URL-urilor și se pot folosi direct și se elimină complet procesul de umplere a formularului.
  • Există o limitare a numărului de date de formă care pot fi trimise, deoarece lungimile adreselor URL sunt limitate.
  • Copiii Script pot expune mai ușor vulnerabilitățile din sistem pentru a le compromite. De exemplu, Citibank a fost hacked prin schimbarea numerelor de cont în șirul de adrese URL.[1] Desigur, hackerii experimentați sau dezvoltatorii web pot expune astfel de vulnerabilități, chiar dacă se utilizează POST; este doar un pic mai greu. În general, serverul trebuie să fie suspicios față de orice date trimise de client și să se ferească de referințele de obiecte directe nesigure.

Diferențe în procesarea pe server

Î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.

Utilizare recomandată

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:

  • Dacă datele formularului ar conține caractere non-ASCII (cum ar fi caracterele accentuate), atunci Method = "GET" este inaplicabilă în principiu, deși poate funcționa în practică (în special pentru caracterele ISO latine 1).
  • Dacă setul de date al formularului este mare - spunem, sute de caractere - atunci Method = "GET" poate provoca probleme practice cu implementările care nu pot gestiona acele adrese URL lungi.
  • S-ar putea să doriți să evitați Method = "GET" pentru a face mai puțin vizibil pentru utilizatori cum funcționează formularul, mai ales pentru a face câmpurile "ascunse" (INPUT TYPE = "HIDDEN") mai ascunse prin faptul că nu apar în URL. Dar chiar dacă utilizați câmpuri ascunse Method = "POST", acestea vor apărea în continuare în codul sursă HTML.

Ce despre HTTPS?

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:

  1. Faptul că ați realizat o conexiune HTTPS
  2. Numele gazdei - www.example.com
  3. Lungimea totală a cererii
  4. Lungimea răspunsului

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.

Referințe

  • wikipedia: POST (HTTP)
  • Metode de solicitare HTTP
  • Mesaj HTTP - W3.org
  • HTTP Get - W3.org
  • HTTPS ascunde adresele URL accesate? - Stack Exchange