Primite post put zahtjeve. Post and Get requests, koja je razlika između njih i što je bolje i za koje namjene

Korištenje GET i POST metoda u PHP-u teško je precijeniti, jer se te metode nalaze na gotovo svakoj web stranici. Prije proučavanja dolje opisanog materijala, savjetujem vam da se upoznate s html oznakom

. Pogledajmo svaku od ovih metoda u detalje.

GET metoda

Za prijenos podataka koristi se GET metoda URL niz. Možda ste primijetili dugačke i nejasne URL-ove. Na primjer: funkcija.php?login=Alex&email=dezyakin. U u ovom slučaju podaci se obrađuju u funkciji.php. Nakon upitnika "?" nalazi se popis proslijeđenih parametara (parametri su odvojeni znakom "&") s vrijednostima: parametru za prijavu dodijeljena je vrijednost Alex, a varijabli e-pošte dodijeljena je vrijednost dezyakin. Podaci će biti pohranjeni u superglobalnom polju $_GET. Primjer korištenja GET metode prikazan je u nastavku:

Prijaviti se: Email: Koristeći superglobalni niz $_GET, prikazujemo prihvaćene vrijednosti:*/ jeka "
prijava = ". $_GET["prijava"] ; echo "
email = ". $_GET["email"] ; ?>

Primijetite kako čitamo vrijednosti iz $_GET superglobalnog niza: $_GET["naziv_varijable"]. U našem primjeru, imena varijabli deklarirana su u obliku (ime=prijava i ime=e-mail).

Savjet:
Prije obrade primljenih vrijednosti, savjetujem vam da provjerite njihovo postojanje kroz funkcije isset(ime_varijable) ili prazno(naziv_varijable)- o ovim funkcijama se govorilo u prethodnoj lekciji 2: varijable u PHP-u. Na primjer:

provjera postojanja pomoću isset-a: if isset ($_GET["login"] ) ( operatori za rukovanje prijavom ... } //ili provjerite postojanje koristeći prazno: ako je prazno ($_GET["email"] ) ( operatori za obradu elektronske pošte ... } ?>

U obrascu možete odrediti naziv datoteke koja će obrađivati ​​prenesene vrijednosti. To se radi pomoću atributa oblici djelovanja, kojoj možete dodijeliti adresu ove datoteke. Prema zadanim postavkama ova je datoteka dodijeljena trenutna datoteka(tj. obrađen u datoteci u kojoj se obrazac nalazi). Evo primjera u kojem se podaci iz obrasca prenose u datoteku srcipt.php za obradu:

Prijaviti se: Email:

Datoteka script.php mora sadržavati neku vrstu rukovatelja informacijama, inače će informacije biti proslijeđene kao prazne.

GET metoda ima mnogo nedostataka:

Zbog gore navedenih nedostataka GET metoda koristi se samo u slučajevima kada je potrebno prenijeti malu količinu podataka, a ti podaci nisu klasificirani ni na koji način.

POST metoda

POST metoda razlikuje se od GET-a po tome što se podaci prenose u privatnom obliku. Postoji superglobalni niz $_POST iz kojeg se podaci mogu čitati ovako: $_POST["naziv_varijable"]. Na primjer:

Prijaviti se: "> E-pošta: ">
Koristeći superglobalni niz $_POST, prikazujemo prihvaćene vrijednosti:*/ jeka "
prijava = ". $_POST["prijava"] ; echo "
email = ". $_POST["email"] ; ?>

Rezultat izvršavanja gornjeg koda prikazan je na slici ispod:

Kao što vidite, URL nema postskriptum, ali unatoč tome podaci su primljeni i prikazani.

Bilješka:
1) Količina vrijednosti prenesenih metodom POST ograničena je prema zadanim postavkama i jednaka je 8 MB. Za povećanje ove vrijednosti morate promijeniti post_max_size direktivu u php.ini.

2) U ranijim verzijama PHP-a, umjesto kratkih imena superglobalnih polja $_GET i $_POST, korištena su duža imena: $HTTP_GET_VARS i $HTTP_POST_VARS. Prema zadanim postavkama one su onemogućene u PHP 5, ali ih možete omogućiti u konfiguracijskoj datoteci php.ini pomoću parametra register_long_arrays. U verziji php 6 ova duga imena neće biti dostupna.

3) Prije obrade varijabli iz $_POST, savjetujem vam da provjerite prisutnost varijabli, baš kao što je učinjeno s metodom GET.

Zajedničko im je da rade na isti način. Tehnički nema razlike među njima. Ali postoje ideološke razlike.

Govorit ću o njima u kontekstu PHP-a. Imajte na umu da je HTTP protokol neizravno povezan s PHP-om jer je stvoren za razmjenu html stranica, a PHP jednostavno proširuje mogućnosti oba.

GET zahtjev se koristi za primanje podataka, a POST za slanje. (Zapamtite da tehnički rade isto).

Stoga smo u kontekstu PHP-a, na temelju ove ideologije, učinili sljedeće:
1. Svaki put kada pokrenete PHP, prema zadanim postavkama stvaraju se superglobalni nizovi ($_GET, $_POST).
2. Ako postoji upitnik (?) u nizu upita. Sve nakon toga se razmatra parametri GET zahtjev, oni su predstavljeni u formatu "ključ"="vrijednost", a znak ampersand (&) koristi se kao graničnik.
Primjer:
GET /index.php?name=Andrey&surname=Galkin
Ovo je niz upita, ima 2 parametra. ovi parametri će ići u polje $_GET.
3. $_POST se popunjava na drugačiji način. sadržaj ovog niza popunjava se iz "zaglavlja zahtjeva". Odnosno, s mjesta koje je jasno skriveno od pogleda. Preglednik preuzima sve poslove oko stvaranja takvih zaglavlja. Iako se ponekad nešto ručno uredi u naslovima.

Najčešće se post zahtjev koristi u obrascima (za slanje podataka).

Na primjer, imamo obrazac za prijavu s 2 polja: prijavu i lozinku.

Zamislimo da koristimo metodu GET. Tada ćemo prilikom podnošenja obrasca otići na sljedeću adresu /login.php?login=Andrey&password=123 Složit ćete se da prijenos takvih informacija na ovaj način nije nimalo siguran. Svatko može otvoriti vaš preglednik i, počevši unositi adresu stranice, moći će vidjeti vaše lozinke i prijave iz povijesti.

Ali ako smo naveli metodu POST, dobili bismo sljedeći zahtjev:
POST /login.php (login=Andrey&password=123) ono što je u zagradama bilo bi skriveno i ni na koji način ne bi bilo spremljeno u pregledniku.

Da sažmemo:
GET je dobiti određenu stranicu u određenom obliku (razvrstavanje, trenutna stranica bloga, traka za pretraživanje, itd.).
POST - za slanje podataka koji ne utječu na prikaz stranice, u smislu da ti podaci utječu samo na rezultat skripte (prijave, lozinke, brojevi kreditnih kartica, poruke itd.).

A još jedna dobra vijest je da se mogu kombinirati npr
POST /index.php?page=login (login=Andrey&password=123) Mislim da sam već dovoljno objasnio što će od ovoga biti i koji će parametri ići u koji niz.

1. HTTP protokol. Uvod

Htio bih odmah pojasniti jednu sitnicu. Strašna riječ protokol nije ništa drugo nego dogovor mnogih ljudi, samo su u jednom lijepom trenutku ljudi odlučili: “Ajmo ovako, pa će onda sve biti u redu.” Nema se čega bojati, sve je jednostavno nečuveno i sada ćemo otkriti ovu sramotu. Dakle, što je HTTP protokol i za što se koristi?

1.1 Klijent i poslužitelj

Nema čuda u svijetu, a pogotovo u svijetu programiranja i interneta! Prihvatite ovo kao nepokolebljivu istinu. A ako program ne radi ili ne radi kako želite, onda je najvjerojatnije ili pogrešno napisan ili sadrži pogreške. Dakle, kako preglednik traži od poslužitelja da mu bilo što pošalje? Da, vrlo jednostavno! Samo se trebate malo opustiti i početi uživati ​​u procesu :-)

1.2. Pisanje našeg prvog HTTP zahtjeva

Ako mislite da je sve prekomplicirano, varate se. Čovjek je dizajniran na takav način da jednostavno nije sposoban stvoriti nešto složeno, inače će se i sam zbuniti u tome :-) Dakle, postoji preglednik i postoji web poslužitelj. Preglednik je uvijek inicijator razmjene podataka. Web-poslužitelj nikada neće jednostavno poslati nešto bilo kome tako da pošalje nešto pregledniku - preglednik to mora zatražiti. Najjednostavniji HTTP zahtjev mogao bi izgledati ovako:


PREUZMITE http : //www.php.net/ HTTP/1.0rnrn


* GET (u prijevodu s engleskog znači “dobiti”) - vrsta zahtjeva, tip zahtjeva može biti različit, na primjer POST, HEAD, PUT, DELETE (neke od njih ćemo pogledati u nastavku).
* http://www.php.net/ - URI (adresa) s koje želimo primati barem neke informacije (naravno, nadamo se da ćemo naučiti HTML stranicu).
* HTTP/1.0 - vrsta i verzija protokola koji ćemo koristiti u komunikaciji s poslužiteljem.
* rn - kraj retka, koji se mora ponoviti dva puta, postat će jasno malo kasnije;

Ovaj zahtjev možete izvršiti vrlo jednostavno. Pokrenite program telnet.exe, unesite www.php.net kao host, navedite port 80 i jednostavno upišite ovaj zahtjev pritiskom na Enter dva puta kao rnrn. Kao odgovor dobit ćete HTML kod glavne stranice web stranice www.php.net.

1.3 Struktura zahtjeva

Pogledajmo od čega se sastoji HTTP zahtjev. Sve je vrlo jednostavno. Počnimo s činjenicom da je HTTP zahtjev potpuno smislen tekst. Od čega se sastoji u općem slučaju? Razmotrit ćemo HTTP 1.0 protokol. Tako :


Zahtjev - Redak [ Općenito - Zaglavlje | Zahtjev - Zaglavlje | Entitet - Zaglavlje ] rn [ Entitet - Tijelo ]


* Request-Line - linija zahtjeva
*

Format : "Metoda Request-URI HTTP-Versionrn"
* Metoda - metoda kojom će se resurs Request-URI obraditi može biti GET, POST, PUT, DELETE ili HEAD.
* Request-URI - relativna ili apsolutna poveznica na stranicu sa skupom parametara, na primjer, /index.html ili http://www.myhost.ru/index.html ili /index.html?a=1&b= qq. U potonjem slučaju, poslužitelju će biti poslan zahtjev sa skupom varijabli a i b s odgovarajućim vrijednostima, a znak "&" - ampersand - služi kao razdjelnik između parametara.
* HTTP-Version - verzija HTTP protokola, u našem slučaju "HTTP/1.0".

Iznimno smo zainteresirani za GET i POST metode obrade. Metodom GET možete jednostavno proslijediti parametre skripti, a metodom POST možete emulirati slanje obrasca.

Za metodu GET, Request-URI može izgledati ovako: "/index.html?param1=1¶m2=2".

* General-Header - glavni dio zaglavlja.
Format:
Može imati samo dva parametra: Datum ili Pragma. Datum - Greenwich datum u formatu "Dan u tjednu, Dan Mjesec Godina HH:MM:SS GMT", na primjer, "Tue, 15 Nov 1994 08:12:31 GMT" - datum kreiranja zahtjeva. Pragma može imati jednu vrijednost bez predmemoriranja, koja onemogućuje predmemoriranje stranice.

* Request-Header - dio zaglavlja koji opisuje zahtjev.

Zaglavlje zahtjeva može imati sljedeće parametre : Dopusti, Autorizacija, Od, Ako je promijenjeno od, Preporuka, Korisnički agent.
U ovom poglavlju nećemo razmatrati parametar Autorizacija, budući da se koristi za pristup privatnim resursima, što nije često potrebno. Možete naučiti kako sami izraditi zaglavlje ovlaštenog pristupa na www.w3c.org.

* Dopusti - postavlja prihvatljive metode obrade.
Format: "Dopusti: GET | HEADn".
Parametar se zanemaruje kada se navede POST metoda obrade u retku zahtjeva. Određuje prihvatljive metode obrade zahtjeva. Proxy poslužitelji ne mijenjaju parametar Allow i on do poslužitelja dolazi nepromijenjen.

* Od - e-mail adresa osobe koja je poslala zahtjev.
Format: "Od: adderssrn".
Na primjer, "Od: [e-mail zaštićen]".

* If-Modified-Since - označava da zahtjev nije modificiran od tog i tog vremena.
Format: "If-Modified-Since: datern"
Koristi se samo za GET metodu obrade. Datum je naveden u GMT-u u istom formatu kao za parametar Datum u Općem zaglavlju.

* Referrer - apsolutni link na stranicu s koje je zahtjev pokrenut, odnosno link na stranicu s koje je korisnik došao na našu.
Format: "Preporuka: url".
Primjer: "Preporuka: www.host.ru/index.htmln".
* User-Agent - vrsta preglednika.
Na primjer: "Korisnički agent: Mozilla/4.0n"

* Entity-Header - dio zaglavlja koji opisuje podatke Entity-Body.
Ovaj dio zahtjeva specificira parametre koji opisuju tijelo stranice. Entity-Header može sadržavati sljedeće parametre: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.

* Dopusti - parametar sličan Dopusti iz Općeg zaglavlja.

* Kodiranje sadržaja - vrsta kodiranja podataka entiteta i tijela.
Format: "Kodiranje sadržaja: x-gzip | x-compress | druga vrsta".
Primjer: "Kodiranje sadržaja: x-gzipn". Znak "|". znači riječ "ili", odnosno ovo ili ono ili ono itd.
Drugi tip može označavati kako su podaci kodirani, na primjer, za POST metodu: "Content-Encoding: application/x-www-form-urlencodedn".

* Content-Length - broj bajtova koji se šalju tijelu entiteta. Vrijednost Content-Length ima potpuno drugačije značenje za podatke poslane u MIME formatu, gdje djeluje kao parametar za opisivanje dijela podataka - "external/entity-body". Važeći brojevi su cijeli brojevi od nule naviše.
Primjer: "Duljina sadržaja: 26457n".

* Content-Type - vrsta prenesenih podataka.
Na primjer: "Content-Type: text/htmln".

* Istječe - Vrijeme kada se stranica treba izbrisati iz predmemorije preglednika.
Format: "Ističe: datum". Format datuma je isti kao format datuma za parametar Datum iz General-Header.

* Last-Modified - vrijeme zadnje promjene poslanih podataka.
Format: "Zadnja izmjena: s datumom". Format datuma je isti kao format datuma za parametar Datum iz General-Header.

* Extention-header - dio zaglavlja, koji može biti namijenjen, na primjer, za obradu u pregledniku ili drugom programu koji prima dokument. U ovom dijelu možete opisati svoje parametre u formatu "Naziv parametra: vrijednost parametra". Ovi parametri će biti zanemareni ako klijentski program ne zna kako ih obraditi.
Na primjer: "Cookie: r=1rn" - postavlja dobro poznate kolačiće za stranicu.

A sada, nakon tako strašnih riječi, pokušajmo se malo smiriti i shvatiti što nam treba? Naravno, razumjet ćemo s primjerima.

Zamislimo da trebamo dobiti stranicu sa stranice prosljeđivanjem kolačića, inače ćemo jednostavno biti poslani kao nepozvani gosti, a štoviše, poznato je da vam je dopušten pristup ovoj stranici tek nakon što ste posjetili glavnu stranicu mjesto.

2 GET metoda

Napišimo naš zahtjev.


PREUZMI http:
Domaćin: www. mjesto. trčati

Kolačić: prihod = 1rn
rn


Ovaj zahtjev nam govori da želimo dobiti sadržaj stranice na http://www.site.ru/news.html koristeći metodu GET. Polje Host označava da se ova stranica nalazi na serveru www.site.ru, polje Referer označava da smo došli po vijesti s glavne stranice stranice, a polje Cookie označava da nam je dodijeljen taj i takav kolačić. Zašto su polja Host, Referer i Cookie tako važna? Budući da normalni programeri, kada stvaraju dinamičke stranice, provjeravaju podatkovna polja koja se pojavljuju u skriptama (uključujući PHP) u obliku varijabli. Za što je ovo? Kako bi, na primjer, spriječili pljačku stranice, tj. nisu postavili program na njemu za automatsko preuzimanje, ili da osoba koja posjećuje stranicu uvijek dolazi samo s glavne stranice itd.

Sada zamislimo da trebamo ispuniti polja obrasca na stranici i poslati zahtjev iz obrasca, neka u ovom obrascu budu dva polja: prijava i lozinka (prijava i lozinka) - i, naravno, znamo prijavu i lozinku.


PREUZMI http: //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0rn
Domaćin: www. mjesto. trčati
Preporuka: http: //www.site.ru/index.htmlrn
Kolačić: prihod = 1rn
rn


Naša prijava je "Petya Vasechkin" Zašto bismo trebali pisati Petya%20Vasechkin? To je zato što poslužitelj može prepoznati posebne znakove kao znakove prisutnosti novog parametra ili kraja zahtjeva itd. Stoga postoji algoritam za kodiranje naziva parametara i njihovih vrijednosti kako bi se izbjegle situacije pogreške u zahtjevu. Potpuni opis ovog algoritma može se pronaći ovdje, a PHP ima funkcije rawurlencode i rawurldecode za kodiranje odnosno dekodiranje. Želio bih napomenuti da PHP sam dekodira ako su u zahtjevu proslijeđeni kodirani parametri. Ovime završavam prvo poglavlje mog upoznavanja s HTTP protokolom. U sljedećem poglavlju ćemo pogledati zahtjeve za izgradnju kao što je POST (prevedeno s engleskog kao "pošalji"), što će biti mnogo zanimljivije, jer Ovo je tip zahtjeva koji se koristi pri slanju podataka iz HTML obrazaca.

3. POST metoda.

U slučaju HTTP POST zahtjeva, postoje dvije opcije za prijenos polja iz HTML obrazaca, naime, pomoću algoritma application/x-www-form-urlencoded i multipart/form-data. Razlike između ovih algoritama su prilično značajne. Činjenica je da je prvi tip algoritma nastao davno, kada HTML jezik još nije davao mogućnost prijenosa datoteka putem HTML obrazaca. Dakle, pogledajmo ove algoritme s primjerima.

3.1 Content-Type: application/x-www-form-urlencoded.

Pišemo zahtjev sličan našem GET zahtjevu za prijenos prijave i lozinke, o čemu smo govorili u prethodnom poglavlju:


OBJAVI http: //www.site.ru/news.html HTTP/1.0rn
Domaćin: www. mjesto. trčati
Preporuka: http: //www.site.ru/index.htmlrn
Kolačić: prihod = 1rn
Sadržaj - Tip : prijava / x - www - obrazac - urlencodedrn
Sadržaj - Duljina : 35rn
rn


Ovdje vidimo primjer korištenja polja zaglavlja Content-Type i Content-Length. Content-Length govori koliko će bajtova zauzimati područje podataka, koje je odvojeno od zaglavlja drugim redom rn. Ali parametri koji su prethodno bili smješteni u Request-URI za GET zahtjev sada su u Entity-Body. Vidi se da su oblikovane na potpuno isti način, samo ih treba napisati iza naslova. Želio bih napomenuti još jednu važnu točku: ništa ne sprječava, istovremeno sa skupom parametara u Entity-Body, postavljanje parametara s drugim imenima u Request-URI, na primjer:


OBJAVI http: //www.site.ru/news.html?type=user HTTP/1.0rn
.....
rn
prijava = Petya % 20Vasechkin & lozinka = qq


3.2 Content-Type: multipart/form-data

Čim je internetski svijet shvatio da bi bilo lijepo slati datoteke putem obrazaca, konzorcij W3C krenuo je s usavršavanjem formata POST zahtjeva. U to vrijeme MIME format (Multipurpose Internet Mail Extensions - višenamjenska proširenja protokola za generiranje Mail poruka) već je bio široko korišten, stoga smo, kako ne bismo ponovno izmišljali kotač, odlučili koristiti dio ovog formata za generiranje poruka za stvaranje POST zahtjevi u HTTP protokolu.

Koje su glavne razlike između ovog formata i application/x-www-form-urlencoded tipa?

Glavna razlika je u tome što se entitet-tijelo sada može podijeliti na dijelove, koji su odvojeni granicama (granica). Ono što je najzanimljivije je da svaki odjeljak može imati svoje zaglavlje za opis podataka koji su u njemu pohranjeni, tj. u jednom zahtjevu možete prenijeti podatke različitih vrsta (kao u Mail pismu, možete prenijeti datoteke u isto vrijeme kao i tekst).

Pa krenimo. Razmotrimo ponovno isti primjer s prijenosom prijave i lozinke, ali sada u novom formatu.


OBJAVI http: //www.site.ru/news.html HTTP/1.0rn
Domaćin: www. mjesto. trčati
Preporuka: http: //www.site.ru/index.htmlrn
Kolačić: prihod = 1rn

Sadržaj - Duljina : 209rn
rn
-- 1BEF0A57BE110FD467Arn
Sadržaj - dispozicija : obrazac - podaci ; ime = "prijava" rn
rn
Petya Vasechkinrn
-- 1BEF0A57BE110FD467Arn
Sadržaj - dispozicija : obrazac - podaci ; ime = "lozinka" rn
rn
qqrn
-- 1BEF0A57BE110FD467A -- rn


Sada shvatimo što je napisano. :-) Namjerno sam podebljao neke rn znakove da se ne stapaju s podacima. Ako pažljivo pogledate, primijetit ćete rubno polje nakon Content-Type. Ovo polje specificira separator odjeljka - rub. Niz koji se sastoji od latiničnih slova i brojeva, kao i nekih drugih simbola (nažalost, ne sjećam se kojih) može poslužiti kao rub. U tijelu zahtjeva na početak granice se dodaje “--”, a zahtjev završava granicom kojoj se na kraj također dodaju znakovi “--”. Naš zahtjev ima dva odjeljka, prvi opisuje polje za prijavu, a drugi polje za lozinku. Content-Disposition (tip podataka u odjeljku) govori da će to biti podaci iz obrasca, a polje name navodi naziv polja. Ovdje završava zaglavlje odjeljka i ono što slijedi je područje podataka odjeljka u koje se nalazi vrijednost polja (nije potrebno kodirati vrijednost!).

Želio bih vam skrenuti pozornost na činjenicu da ne morate koristiti Content-Length u zaglavljima odjeljaka, ali u zaglavlju zahtjeva biste trebali i njegova je vrijednost veličina cijelog Entity-Body-a, koji se pojavljuje nakon drugog rn sljedeći Sadržaj-Dužina: 209rn. Oni. Tijelo entiteta odvojeno je od zaglavlja dodatnim prijelomom retka (koji se također može vidjeti u odjeljcima).

Sada napišimo zahtjev za prijenos datoteke.


OBJAVI http: //www.site.ru/postnews.html HTTP/1.0rn
Domaćin: www. mjesto. trčati
Preporuka: http : //www.site.ru/news.htmlrn
Kolačić: prihod = 1rn
Content-Type: multipart/form-data; granica = 1BEF0A57BE110FD467Arn
Sadržaj - Duljina : 491rn
rn
-- 1BEF0A57BE110FD467Arn
Sadržaj - dispozicija : obrazac - podaci ; naziv = "zaglavlje_vijesti" rn
rn
Primjer newsrn
-- 1BEF0A57BE110FD467Arn
Sadržaj - dispozicija : obrazac - podaci ; naziv = "datoteka_vijesti" ; naziv datoteke = "vijesti.txt" rn
Sadržaj - Vrsta: aplikacija / oktet - streamrn
Sadržaj - Prijenos - Kodiranje: binaryrn
rn
Evo novosti, koji se nalazi u datoteci vijesti. txtrn
-- 1BEF0A57BE110FD467A -- rn


U ovom primjeru, prvi odjeljak šalje naslov vijesti, a drugi odjeljak šalje datoteku news.txt. Ako ste pažljivi, vidjet ćete polja za naziv datoteke i vrstu sadržaja u drugom odjeljku. Polje naziva datoteke navodi naziv datoteke koja se šalje, a polje Vrsta sadržaja navodi vrstu ove datoteke. Application/octet-stream označava da je ovo standardni tok podataka, a Content-Transfer-Encoding: binary označava da su to binarni podaci, koji nisu kodirani ni na koji način.

Vrlo važna točka. Većinu CGI skripti pišu pametni ljudi, pa vole provjeriti vrstu dolazne datoteke, koja se nalazi u Content-Type. Za što? Najčešće se učitavanje datoteka na web stranice koristi za primanje slika od posjetitelja. Dakle, sam preglednik pokušava odrediti koju vrstu datoteke posjetitelj želi poslati i ubacuje odgovarajući Content-Type u zahtjev. Skripta ga provjerava po primitku i, na primjer, ako nije gif ili jpeg, zanemaruje ovu datoteku. Stoga, kada kreirate zahtjev "ručno", vodite računa o vrijednosti Content-Type tako da bude najbliža formatu datoteke koja se prenosi.

Slika/gif za gif
slika/jpeg za jpeg
slika/png za png
slika/tiff za tiff (koji se koristi izuzetno rijetko, format je prevelik)

U našem primjeru generira se zahtjev u kojem se prenosi tekstualna datoteka. Na isti način se generira zahtjev za prijenos binarne datoteke.

4. Postskriptum.

Mislim da ne vrijedi detaljno govoriti o slanju zahtjeva poslužitelju. Ovo je stvar čisto RHP tehnologije :-). Dovoljno je pažljivo pročitati odjeljak o funkcijama za rad sa utičnicama, odnosno o funkcijama CURL modula u službenoj PHP dokumentaciji.

Iz gore navedenog, nadam se da je sada jasno zašto je pitanje: "Kako mogu generirati POST zahtjev pomoću funkcije zaglavlja?" - besmisleno. Funkcija header(string) dodaje unos samo u zaglavlje zahtjeva, ali ne i u tijelo zahtjeva.

leđa

HTTP je hipertekstualni transportni protokol, jedan od protokola u TCP/IP skupu. Protokol je izvorno stvoren za slanje i primanje HTML stranica, ali sada se dobro koristi za distribuirane informacijske sustave. To je jedan od najčešće korištenih protokola na World Wide Webu.

Slika 1

Na temelju sheme zahtjev/odgovor. Kada klijent pošalje zahtjev poslužitelju, to može učiniti pomoću 3 vrste zahtjeva: GET, PUT i POST.

GET zahtjev HTTP protokola

DOBITI je zahtjev klijenta za informacijama. Klijentov web preglednik šalje GET poruku da dohvati stranice s njega. Zahtjev ima dva dijela:

  • niz upita
  • zaglavlja

GET zahtjev nema tijelo podataka, ali to ne znači da ne može prenijeti podatke na poslužitelj. Pomoću posebnih parametara u retku URL-a možete prenijeti podatke na poslužitelj. Znak ? iza domene u URL-u znači da će se proslijediti daljnji parametri. Slika 2 točno prikazuje koje informacije preglednik prenosi poslužitelju.

Slika - 2

POST i PUT zahtjev HTTP protokola

Ove dvije metode implementirane su kako bi se informacije poslale web poslužitelju. Na primjer, pomoću posebnih web obrazaca, nakon što ih ispunimo, šaljemo ih na poslužitelj metodom POST. PUT učitava resurse ili podatke na web poslužitelj (slike, video).

HTTP nije siguran protokol i POST poruke se mogu presresti i pročitati jer nisu šifrirane. Kako bi se osigurala sigurnost prijenosa podataka POST metodom, koristi se HTTPS protokol. Šifrira podatke i može izvršiti autentifikaciju. Također implementira dodatne zahtjeve za prijenos informacija između transportnog i aplikacijskog sloja.

Glavne razlike između metoda POST i GET prikazane su u tablici 1.

Slika 3 prikazuje osnovna pravila kojih se morate pridržavati pri odabiru GET ili POST metode za implementaciju rada na vašem poslužitelju.

Dugo sam želio napisati članak u kojem bih govorio o razlika između POST metode i GET metode, ali nekako su se pojavile druge teme i prebacio sam se na njih. I sada je konačno došlo vrijeme da se obradi ova tema, jer ljudi često jednostavno ne znaju koja je razlika između POST i GET.

Za jasniji prikaz razlika između POST i GET, dajem tablicu koja pokazuje po kojim se karakteristikama razlikuju.

Na temelju ove karakteristike možemo zaključiti kada koristiti POST, i kada DOBITI. Na primjer, ako korisnik želi označiti generiranu stranicu. Tada bi se generacija trebala dogoditi do GET zahtjev, inače nećete moći označiti stranicu. Drugi primjer: kada prosljeđujete prijavu i lozinku, ne možete postaviti metodu DOBITI, budući da se temelji na prijenosu podataka kroz adresnu traku. Inače, nakon pritiska na tipku " podnijeti", nešto poput ovoga pojavit će se u adresnoj traci: " http://mysite.ru/login.php?log=User&pass=123456", - i svatko može vidjeti lozinku, što, naravno, ne bi trebalo biti dopušteno. Stoga, ovdje morate koristiti metodu POST.

Također, ne zaboravite da je veličina podataka koja se može proslijediti metodom POST, red veličine veći nego kada se prenosi metodom DOBITI. Općenito, analizirajte ovu tablicu i izvucite zaključak: koji način prijenosa podataka treba koristiti u određenom slučaju. To ću dodati u svoje osobno ime 80% moraju se koristiti slučajevi POST, ali ne zaboravite da je to daleko od toga 100% .

Ako imate pitanja ili želite komentirati ovaj članak, svoj komentar možete ostaviti na dnu stranice.

Komentari (15):

dsmts 12.05.2013 14:00:18

Dobar dan Trebam ovako nešto prilikom preusmjeravanja: header("Lokacija: test.php"); Vrijednost $_POST proslijeđena je ovoj stranici. Stranica s koje se ova vrijednost treba prenijeti nema nikakvih obrazaca. Oni. jednostavno obrađuje podatke i generira određeni zahtjev. Trenutačno imam prijenos obavljen pomoću kolačića. Ali nisam siguran je li sigurno. Ili sam u krivu? Podaci koji se prenose ne bi trebali biti vidljivi korisnicima.

Odgovor

Alex_ 23.11.2013 23:56:10

Dobar dan :), Mikhail! Pokušavam napisati dodatak u PHP-u i prirodno sam otkrio da mi nedostaje znanja. Otuda i pitanje: ako mi određena stranica (platni sustav), nakon mojih radnji s moje strane, pošalje podatke na stranicu na određenoj stranici metodom POST, trebam li ih vidjeti ako u skripti napišem print_r($_POST) ? ? Samo u mom slučaju, na primjer print_r($_SERVER); vidi se koji su podaci u $_SERVER nizu, ali $_POST je prazan, odnosno ili podaci ne stižu ili imam profani pogled na to kako stvari stvarno stoje.

Odgovor

23.11.2013 23:59:31

Pozdrav, Alexander. Obično sustavi plaćanja prenose podatke obrnutim redoslijedom u šifriranom obliku i korištenjem sigurnih protokola. Dakle, sve ovisi o sustavu plaćanja. Pišete li modul plaćanja za određeni sustav? Molimo pojasnite svoje upite inače vam neću moći pomoći.

Odgovor

Alex_ 24.11.2013 02:00:41

Pozdrav Aleksandre, hvala na odgovoru. Pišem dodatak za cms Wordpress, koji radi sa sustavom plaćanja interkassa.com. Ako je kupnja uspješna, preusmjerava se na stranicu za uspješno plaćanje http://my_site/success. Na ovu stranicu prema dokumentaciji dolaze podaci koji su meni vidljivi. Odnosno u postavkama sam odabrao metodu prijenosa GET i dolazi dugački url, ovaj link i u njemu parametri http://my_site/success/?&ik_payment_id=1&ik_paysystem_alias=yandexdengir, sve je kako treba. Pokušao sam odabrati metodu prijenosa POST, a zatim u skripti koju sam napisao, na primjer, if (isset($_POST["ik_trans_id"])) echo $_POST["ik_trans_id"]. I uspjelo je. Onda sam počeo raditi sa STATUS url-om jer tada dolazi ik_sign_hash kojeg generira intercash pomoću tajnog ključa (koji je poznat meni i intercash-u) i ovaj put ako (isset($_POST["ik_sign_hash"]) ne radi jer ga nema. Na mojoj stranici postoji dodatak (ne radi sve kako bismo htjeli) napisan u OOP-u (još sam daleko od razine onoga koji je ovo napisao, možda zato nije očito). meni što se tamo koristi). Ovaj dodatak obrađuje sve i izračunava hash na svojoj strani, jer sam namjerno promijenio tajni ključ (u postavkama dodatka) i poslana je e-pošta s obavijesti o netočno prenesenim podacima (). hashovi se nisu slagali) i zahtjev za kontakt s administratorom stranice.

Odgovor

24.11.2013 02:09:28

Pa, nisam vidio vaš dodatak, pa neću reći ništa konkretno. Što se tiče jednostavne implementacije...nisam proučavao interkassa API. Ovdje možete vidjeti jednostavno rješenje: http://goo.gl/rFnpNc U suštini, isto je u svim sustavima. Obično radim s robotskom blagajnom ili onpeijem, pa me ispričajte. Općenito, struktura je otprilike ovakva. Trebate napisati implementaciju u skladu s API dokumentacijom http://www.interkassa.com/faq.php pogledajte odjeljak Interkassa očima programera i administratora. u zadnjem pitanju je tehnička dokumentacija za download i općenito sitnice o API-ju

Odgovor

Alex_ 24.11.2013 02:16:40

Hvala ti, Alexander. Vidio sam, pročitao sve ovo, pokušavam već nekoliko dana i guglam pa mislim da mi možda nešto nije jasno :). http://goo.gl/rFnpNc - a ovo je dodatak Andreja Morkovina, koji nije u potpunosti napisan (vjerojatno da ne bismo otkrili sve tajne, skripta se sada plaća). Na temelju njega napravljeno je nekoliko video lekcija o tome kako napisati dodatke na WP. Ovaj dodatak http://www.icprojects.net/paid-downloads-plugin.html dostupan je u plaćenoj i besplatnoj verziji. U besplatnoj verziji dostupno je samo plaćanje putem PAYPAL-a. ali sve je tu i ako promijenite par vrijednosti, Interkassa mod u beta verziji postaje dostupan.

Odgovor

24.11.2013 02:23:00

Da, svjestan sam toga, bio je potpun ili ne, možda negdje postoji verzija koja košta 40 USD. ležati uokolo. U svakom slučaju, neću preporučiti ništa konkretno. Pročitajte Interkassa API dokumentaciju i algoritmi su svugdje isti. Možete pogledati Levchukovo rješenje na njegovoj wpstranici ;) Ako budem imao vremena, pogledat ću ovu temu detaljnije



POVEZANI ČLANCI

Preporučujemo

Copyright 2024 - Popravak računala i prijenosnih računala. Video kartice, tvrdi diskovi, internet, monitori.