Differkinome

GET pret POST

Tehnoloģijas
Share

HTTP POST pieprasa no klienta (pārlūkprogrammas) piegādāt papildu datus serverim ziņojuma pamattekstā. Pretstatā tam, GŪT pieprasījumos URL ir ietverti visi nepieciešamie dati. Veidlapās HTML var norādīt jebkuru no šīm metodēm metode = "POST" vai metode = "GET" (noklusējums) elements. Norādītā metode nosaka, kā veidlapas dati tiek iesniegti serverī. Ja metode ir GET, visi veidlapas dati tiek kodēti URL, kas pievienoti darbība URL kā vaicājuma virknes parametri. Izmantojot POST, formas dati parādās HTTP pieprasījuma ziņojuma pamattekstā.

Salīdzināšanas tabula

GET un POST salīdzināšanas diagramma
GŪTPOST
Vēsture Parametri paliek pārlūkprogrammas vēsturē, jo tie ir daļa no URL Parametri netiek saglabāti pārlūka vēsturē.
Grāmatzīmēm Var atzīmēt ar grāmatzīmēm. Nevar pievienot grāmatzīmēm.
Poga ATPAKAĻ / atkārtota izturēšanās GET pieprasījumi tiek atkārtoti izpildīti, bet tos nevar atkārtoti iesniegt serverī, ja HTML ir saglabāts pārlūka kešatmiņā. Parasti pārlūks brīdina lietotāju, ka dati būs jāiesniedz atkārtoti.
Kodēšanas tips (enctype atribūts) pieteikums / x-www-form-urlencoded multipart / form-data vai application / x-www-form-urlencoded Binārajiem datiem izmantojiet daudzdaļu kodējumu.
Parametri var sūtīt, bet parametru dati ir ierobežoti ar to, ko mēs varam ievietot pieprasījuma rindā (URL). Drošākais ir izmantot mazāk par 2K parametru, daži serveri apstrādā līdz 64K Var nosūtīt parametrus, ieskaitot failu augšupielādi, uz serveri.
Ielauzts Vieglāk uzlauzīt skriptu kiddies Grūtāk kapāt
Veidlapas datu veida ierobežojumi Jā, atļautas tikai ASCII rakstzīmes. Nav ierobežojumu. Ir atļauti arī bināri dati.
Drošība GET ir mazāk drošs nekā POST, jo nosūtītie dati ir daļa no URL. Tātad tas tiek saglabāts pārlūka vēsturē un servera žurnālos vienkāršā tekstā. POST ir nedaudz drošāks nekā GET, jo parametri netiek saglabāti pārlūka vēsturē vai tīmekļa servera žurnālos.
Veidlapas datu garuma ierobežojumi Jā, jo veidlapas dati atrodas URL un URL garums ir ierobežots. Droša URL garuma ierobežojums bieži ir 2048 rakstzīmes, taču tas atšķiras atkarībā no pārlūka un tīmekļa servera. Nav ierobežojumu
Izmantojamība Sūtot paroles vai citu sensitīvu informāciju, GET metodi nevajadzētu izmantot. POST metode, ko izmanto, nosūtot paroles vai citu sensitīvu informāciju.
Redzamība GET metode ir redzama visiem (tā tiks parādīta pārlūka adreses joslā), un tai ir ierobežojumi nosūtāmās informācijas apjomam.. POST metodes mainīgie URL netiek parādīti.
Kešatmiņā Var saglabāt kešatmiņā Nav kešatmiņā

Saturs: GET vs POST

  • 1 Atšķirības veidlapu iesniegšanā
    • 1.1 Plusi un mīnusi
  • 2 Atšķirības servera puses apstrādē
  • 3 Ieteicamais lietojums
  • 4 Kas par HTTPS?
  • 5 atsauces

Atšķirības formas iesniegšanā

Būtiskā atšķirība starp METODE = "SAŅEMT" un METODE = "POST" ir tas, ka tie atbilst dažādi HTTP pieprasījumi, kā noteikts HTTP specifikācijās. Iesniegšanas process abām metodēm sākas tādā pašā veidā - pārlūkprogramma izveido veidlapu datu kopu un pēc tam kodē veidā, ko norādījis enctype atribūts. Priekš METODE = "POST enctype atribūts var būt daudzdaļīgi / formas dati vai pieteikums / x-www-form-urlencoded, tā kā par METODE = "SAŅEMT", tikai pieteikums / x-www-form-urlencoded ir atļauts. Pēc tam šī veidlapas datu kopa tiek pārsūtīta uz serveri.

Veidlapas iesniegšanai ar METHOD = "GET" pārlūkprogramma izveido URL, ņemot darbība atribūts, pievienojot a ? tam pievienojot veidlapu datu kopu (kodēta, izmantojot lietojumprogrammu / x-www-form-urlencoded satura tipu). Pēc tam pārlūks apstrādā šo URL, it kā sekojot saitei (vai tā, it kā lietotājs būtu tieši ierakstījis URL). Pārlūkprogramma sadala URL daļās un atpazīst resursdatoru, pēc tam nosūta šim saimniekam GET pieprasījumu ar pārējo URL kā argumentu. Serveris ņem to no turienes. Ņemiet vērā, ka šis process nozīmē, ka veidlapas dati ir ierobežoti ar ASCII kodiem. Īpaša uzmanība jāpievērš cita veida rakstzīmju kodēšanai un atšifrēšanai, nododot tās caur URL ASCII formātā.

Veidlapas iesniegšana ar METHOD = "POST" izraisa POST pieprasījuma nosūtīšanu, izmantojot darbība atribūts un ziņojums, kas izveidots atbilstoši enctype atribūts.

Plusi un mīnusi

Tā kā veidlapas dati tiek nosūtīti kā URL daļa, kad GŪT tiek izmantots --

  • Veidlapas dati ir ierobežoti ar ASCII kodiem. Īpaša uzmanība jāpievērš cita veida rakstzīmju kodēšanai un atšifrēšanai, nododot tās caur URL ASCII formātā. No otras puses, bināros datus, attēlus un citus failus var iesniegt, izmantojot METODE = "POST"
  • Visi aizpildītie veidlapas dati ir redzami URL. Turklāt tas tiek saglabāts arī lietotāja tīmekļa pārlūkošanas vēsturē / žurnālos. Šie jautājumi rada GŪT mazāk drošs.
  • Tomēr viena no formas datu, kas tiek sūtīti kā URL, priekšrocība ir tā, ka URL var pievienot grāmatzīmēm un tieši izmantot tos, kā arī pilnībā apiet veidlapu aizpildīšanas procesu..
  • Ir ierobežots formas datu nosūtīšanas ierobežojums, jo URL garums ir ierobežots.
  • Skriptu kiddies var vieglāk atklāt sistēmas ievainojamības, lai to uzlauztu. Piemēram, Citibank tika uzlauzts, mainot kontu numurus URL virknē.[1] Protams, pieredzējuši hakeri vai tīmekļa izstrādātāji var atklāt šādas ievainojamības pat tad, ja tiek izmantots POST; tas ir tikai mazliet grūtāk. Kopumā serverim jābūt aizdomīgam attiecībā uz visiem klienta nosūtītajiem datiem un jāaizsargā pret nedrošām tiešajām objekta atsaucēm.

Atšķirības servera puses apstrādē

Principā iesniegtās veidlapas datu apstrāde ir atkarīga no tā, vai tie tiek nosūtīti ar METODE = "SAŅEMT" vai METODE = "POST". Tā kā dati tiek kodēti dažādos veidos, ir nepieciešami dažādi dekodēšanas mehānismi. Tādējādi, vispārīgi runājot, mainot METODI, var būt nepieciešams mainīt skriptu, kas apstrādā iesniegšanu. Piemēram, izmantojot CGI saskarni, skripts saņem datus vides mainīgajā (QUERYSTRING), kad GŪT tiek izmantots. Bet, kad POST tiek izmantots, formas dati tiek nodoti standarta ievades straumē (stdin) un lasāmo baitu skaitu norāda galvenes Satura garums.

Ieteicamais lietojums

Iesniedzot "idempotentās" veidlapas - GET, ieteicams iesniegt GET - tās, kas "būtiski nemaina pasaules stāvokli". Citiem vārdiem sakot, formas, kas ietver tikai datu bāzu vaicājumus. Cita perspektīva ir tāda, ka vairākiem idempotentiem vaicājumiem būs tāds pats efekts kā vienam vaicājumam. Ja ir iesaistīti datu bāzes atjauninājumi vai citas darbības, piemēram, e-pasta aktivizēšana, ieteicams izmantot POST.

No Dropbox izstrādātāju emuāra:

pārlūks precīzi nezina, ko konkrēta HTML forma dara, bet, ja veidlapa tiek iesniegta, izmantojot HTTP GET, pārlūks zina, ka ir droši automātiski atkārtot iesniegšanu, ja ir tīkla kļūda. Veidlapām, kuras izmanto HTTP POST, var nebūt droši mēģināt vēlreiz, tāpēc pārlūks vispirms prasa lietotājam apstiprinājumu.

“GET” pieprasījums bieži ir kešatmiņā, turpretī “POST” pieprasījums diez vai var būt. Vaicājumu sistēmām tam var būt ievērojama efektivitātes ietekme, it īpaši, ja vaicājumu virknes ir vienkāršas, jo kešatmiņā var tikt izmantoti biežākie vaicājumi.

Dažos gadījumos izmantojot POST ieteicams pat idempotentiem jautājumiem:

  • Ja veidlapas datos būtu rakstzīmes, kas nav ASCII (piemēram, ar diakritiskajām zīmēm) METODE = "SAŅEMT" principā nav piemērojams, kaut arī tas var darboties praksē (galvenokārt ISO 1 latīņu burtiem).
  • Ja veidlapas datu kopa ir liela - teiksim, simtiem rakstzīmju - tad METODE = "SAŅEMT" var radīt praktiskas problēmas ar ieviešanu, kas nevar apstrādāt tik garos vietrāžus URL.
  • Jūs varētu vēlēties izvairīties METODE = "SAŅEMT" lai padarītu lietotājiem mazāk pamanāmu, kā veidlapa darbojas, it īpaši, lai padarītu “slēptos” laukus (INPUT TYPE = “HIDDEN”) slēptākus, jo tie neparādās URL. Bet pat ja jūs izmantojat slēptos laukus ar METODE = "POST", tie joprojām parādīsies HTML avota kodā.

Kas par HTTPS?

Atjaunināts 2015. gada 15. maijs: Īpaši, izmantojot HTTPS (HTTP over TLS / SSL), vai POST piedāvā lielāku drošību nekā GET?

Tas ir interesants jautājums. Pieņemsim, ka iesniedzat GET pieprasījumu vietnei: 

 SAŅEMT https://www.example.com/login.php?user=mickey&passwd=mini

Pieņemot, ka jūsu interneta savienojums tiek uzraudzīts, kāda informācija par šo pieprasījumu būs pieejama snooperim? Ja tā vietā tiek izmantots POST un lietotāja un ieejas dati ir iekļauti POST mainīgajos, tas būs drošāk HTTPS savienojumu gadījumā?

Atbilde ir nē. Ja jūs iesniedzat šādu GET pieprasījumu, uzbrucējam, kas pārrauga jūsu tīmekļa trafiku, būs zināma tikai šāda informācija:

  1. Fakts, ka esat izveidojis HTTPS savienojumu
  2. Resursdatora nosaukums - www.example.com
  3. Kopējais pieprasījuma ilgums
  4. Atbildes ilgums

URL ceļa daļa - t.i., faktiskā pieprasītā lapa, kā arī vaicājuma virknes parametri - tiek aizsargāti (šifrēti), kamēr tie atrodas “pa vadu”, t.i., tiek ceļā uz mērķa serveri. Situācija ir tieši tāda pati POST pieprasījumiem.

Protams, tīmekļa serveriem ir tendence visu piekļuves žurnālos reģistrēt visu URL vienkāršā tekstā; tāpēc slepenas informācijas nosūtīšana, izmantojot GET, nav laba ideja. Tas attiecas neatkarīgi no tā, vai tiek izmantots HTTP vai HTTPS.

Atsauces

  • wikipedia: POST (HTTP)
  • HTTP pieprasījuma metodes
  • HTTP ziņa - W3.org
  • HTTP iegūšana - W3.org
  • Vai HTTPS slēpj vietrāžus URL, kuriem piekļūst? - Steku birža
Tehnoloģijas
×