Ovaj post je odgovor na pitanje postavljeno u jednom od mojih članaka.
U ovom članku želim vam reći što su HTTP metode GET / POST / PUT / DELETE i druge, za što su izmišljene i kako ih koristiti u skladu s REST.
HTTP
Dakle, koji je točno jedan od glavnih protokola Interneta? Pedante ću poslati na RFC2616, a ostalo ću reći kao čovjek :)Ovaj protokol opisuje komunikaciju između dva računala (klijent i poslužitelj), na temelju poruka pod nazivom Zahtjev i Odgovor. Svaka poruka se sastoji od tri dijela: početne linije, zaglavlja i tijela. U ovom slučaju potrebna je samo startna linija.
Početne linije za zahtjev i odgovor imaju drugačiji format - zanima nas samo početni red zahtjeva koji izgleda ovako:
METOD URI HTTP / VERZIJA ,
Gdje je METHOD samo metoda HTTP zahtjeva, URI je identifikator resursa, VERSION je verzija protokola (trenutno je relevantna verzija 1.1).
Zaglavlja su zbirka parova ime-vrijednost, odvojenih dvotočkama. U zaglavljima se prenose različiti servisni podaci: kodiranje poruke, naziv i verzija preglednika, adresa s koje je došao klijent (Referrer) i tako dalje.
Tijelo poruke su, zapravo, preneseni podaci. U odgovoru je preneseni podatak, u pravilu, html stranica koju je tražio preglednik, a u zahtjevu, na primjer, u tijelu poruke, prenosi se sadržaj datoteka učitanih na poslužitelj. Ali u pravilu tijelo poruke uopće nije uključeno u zahtjev.
Primjer HTTP komunikacije
Pogledajmo primjer.upit:
GET /index.php HTTP / 1.1 Host: example.com Korisnički agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko / 2008050509 Firefox / 3.0b5 Prihvati: tekst / html Veza: zatvori
Prvi red je redak zahtjeva, ostali su zaglavlja; tijelo poruke nedostaje
Odgovor:
HTTP / 1.0 200 OK Poslužitelj: nginx / 0.6.31 Jezik sadržaja: ru Vrsta sadržaja: tekst / html; charset = utf-8 Content-Length: 1234 Veza: zatvori ... SAMA HTML STRANICA ...
Resursi i metode
Vratimo se na početni niz upita i zapamtite da sadrži parametar kao što je URI. Ovo je skraćenica od Uniform Resource Identifier - uniformni identifikator resursa. Resurs je, u pravilu, datoteka na poslužitelju (primjer URI u ovom slučaju je "/styles.css"), ali općenito, resurs može biti apstraktni objekt ("/ blogs / webdev /" - označava blok "Web development", a ne za određenu datoteku).Vrsta HTTP zahtjeva (također se naziva HTTP metoda) govori poslužitelju koju radnju želimo poduzeti s resursom. U početku (ranih 90-ih) pretpostavljalo se da klijent može htjeti samo jednu stvar od resursa - dobiti ga, ali sada, koristeći HTTP protokol, možete kreirati postove, uređivati profil, brisati poruke i još mnogo toga. A te je radnje teško kombinirati s pojmom "primanje".
Za razlikovanje radnji s resursima na razini HTTP metoda, izmišljene su sljedeće opcije:
- GET - dobivanje resursa
- POST - stvaranje resursa
- PUT - ažuriranje resursa
- DELETE - brisanje resursa
ODMOR dolazi u igru
REST (REpresentational State Transfer) – ovaj termin je 2000. godine skovao Roy Fielding – jedan od programera HTTP protokola – kao naziv za grupu principa za izgradnju web aplikacija. Općenito, REST pokriva šire područje od HTTP-a - može se koristiti na drugim mrežama s drugim protokolima. REST opisuje principe interakcije klijent-poslužitelj, temeljene na konceptima "resurs" i "glagol" (možete ih shvatiti kao subjekt i predikat). U slučaju HTTP-a, resurs je definiran njegovim URI-jem, a glagol je HTTP metoda.REST predlaže napuštanje upotrebe istog URI-ja za različite resurse (to jest, adrese dvaju različitih članaka poput /index.php?article_id=10 i /index.php?article_id=20 nisu REST-način) i korištenje različite HTTP metode za različite radnje. Odnosno, web aplikacija napisana korištenjem REST pristupa će izbrisati resurs kada mu pristupi metodom HTTP DELETE (naravno, to ne znači da biste trebali moći izbrisati sve i svašta, ali bilo koji zahtjev za brisanje aplikacije mora koristiti metodu HTTP DELETE).
REST daje programerima mogućnost pisanja standardiziranih i malo ljepših web aplikacija nego ikad prije. Koristeći REST, URI za dodavanje novog korisnika neće biti /user.php?action=create (metoda GET / POST), već jednostavno /user.php (strogo POST metoda).
Kao rezultat toga, kombiniranjem postojeće HTTP specifikacije i REST pristupa, razne HTTP metode konačno imaju smisla. GET - vraća resurs, POST - stvara novi, PUT - ažurira postojeći, DELETE - briše.
Problemi?
Da, postoji mali problem s primjenom REST-a u praksi. Ovaj problem se naziva HTML.Zahtjevi za PUT/DELETE mogu se poslati putem XMLHttpRequest-a, kontaktiranjem poslužitelja "ručno" (recimo, preko curl-a ili čak putem telneta), ali ne možete napraviti HTML obrazac koji šalje puni PUT/DELETE zahtjev.
Poanta je da vam HTML specifikacija ne dopušta stvaranje obrazaca koji šalju podatke osim putem GET-a ili POST-a. Stoga, za normalan rad s drugim metodama, morate ih umjetno oponašati. Na primjer, u Racku (mehanizam kojim Ruby stupa u interakciju s web poslužiteljem; Rails, Merb i drugi Ruby okviri izrađeni su pomoću Rack-a), možete dodati skriveno polje pod nazivom "_method" u obrazac i odrediti naziv metodu kao vrijednost (na primjer, "PUT") - u ovom slučaju bit će poslan POST zahtjev, ali Rack će se moći pretvarati da je primio PUT, a ne POST.
Trenutno se najčešće koriste samo dvije HTTP metode: GET i POST. No pokazalo se da se i među ova dva "bora" web developeri uspijevaju izgubiti. Za to postoji objašnjenje: obje se metode mogu koristiti za postizanje istog rezultata. Ali treba imati na umu da nepromišljena primjena bilo koje od metoda može dovesti do katastrofalnih posljedica, uključujući velika opterećenja na kanalu i sigurnosne rupe.
Da biste to izbjegli, dovoljno je samo detaljnije razumjeti svrhu i razlike ovih metoda.
Ako se udubite u značenje naziva metoda, mnogo će vam biti jasno. GET (od engleskog primati), t.j. treba koristiti za upite podataka. POST (od engleskog send by mail) - koristimo ga za slanje podataka na server. Čini se da je sve krajnje jednostavno i razumljivo. Ali tko želi razvijati web-mjesta malo kompliciranija od web-mjesta za posjetnice s jednim obrascem za povratne informacije, bolje je bolje upoznati problem.
Sigurni i nesigurni HTTP zahtjevi
HTTP 1.1 specifikacija uvodi dva koncepta: siguran zahtjev i nesiguran zahtjev, točnije, metodu.
Sigurne metode su metode koje mogu zahtijevati samo informacije. Ne mogu promijeniti traženi resurs, ne mogu dovesti do neželjenih rezultata za korisnika, druge osobe ili poslužitelj. Primjeri sigurnih su zahtjev za HTML kodom web stranice ili slike. Sigurne metode su HEAD i GET.
Bilješka
U stvarnosti, obrtnici naravno mogu naštetiti GET zahtjevima. Na primjer, petlje upita.
Nesigurni upiti, kao što su svi već pretpostavili, mogu potencijalno dovesti do loših posljedica ako se ponovno koriste. Takvi zahtjevi mogu promijeniti sadržaj resursa kojem se pristupa. Primjeri takvih zahtjeva: slanje poruka, registracija, online plaćanja. Nesigurne metode su POST, PUT, DELETE.
Idempotentne metode
Idempotencija je svojstvo metoda koje će, s višestrukim ponovljenim pozivima, vratiti isti rezultat, osim ako su informacije zastarjele. To znači da će prilikom pristupa istom URL-u svi korisnici vidjeti istu web stranicu, sliku, video itd. Metode GET, PUT, DELETE imaju ovo svojstvo.
Sada pobliže pogledajmo same GET i POST metode: sastavimo kratak "sažetak" za svaku.
DOBITI
- dizajniran za primanje podataka s poslužitelja;
- tijelo zahtjeva je prazno;
- obrađuju se na strani poslužitelja brže i uz manju potrošnju poslužiteljskih resursa zbog praznog tijela zahtjeva;
- prijenos varijabli se događa u adresnoj traci (tako ga vidi korisnik, tehnički se podaci prenose u retku upita) i stoga su vidljive informacije o varijablama i njihovim vrijednostima (podaci nisu zaštićeni);
- mogućnost prijenosa male količine podataka na poslužitelj: postoje ograničenja u duljini URL-a, što ovisi o pregledniku, na primjer IE6 = 2Kb. Ovo je broj koji Yahoo! programeri preporučuju za ciljanje;
- može prenositi samo ASCII znakove;
- takav se zahtjev može kopirati, spremiti (na primjer, u oznake);
- zahtjev se može keširati (ovo se može kontrolirati);
- dostupni su uvjetni i djelomični zahtjevi kako bi se dodatno smanjilo opterećenje kanala i poslužitelja;
- ne prekida HTTP vezu (kada je način KeepAlive omogućen na poslužitelju).
POST
- dizajniran za slanje podataka na poslužitelj;
- prijenos podataka se događa u tijelu zahtjeva;
- obrada na strani poslužitelja je sporija i "teža" od GET-a, jer osim zaglavlja, trebate raščlaniti tijelo zahtjeva;
- mogućnost prijenosa velikih količina podataka;
- mogućnost prijenosa datoteka;
- stranica generirana metodom POST ne može se označiti kao knjižne oznake;
- prekida HTTP vezu;
- za prijenos čak i vrlo male količine informacija, većina preglednika šalje najmanje dva TCP paketa: zaglavlje, a zatim tijelo zahtjeva.
Ispada da ove dvije metode nisu toliko slične. Korištenje ovoga ili onog treba biti određeno zadatkom koji se radi, a ne činjenicom da se GET standardno koristi ili je s njim lakši za rad. GET je zasigurno bolja opcija u većini slučajeva, posebno kada se gradi brzi AJAX, ali ne zaboravite na njegove nedostatke. Za sebe sam napravio jednostavan algoritam-bilješku o izboru metode.
1. HTTP protokol. Uvod
Samo želim pojasniti jednu malu stvar. Užasna riječ protokol nije ništa drugo nego dogovor mnogih ljudi, samo su u jednom lijepom trenutku ljudi odlučili: "Učinimo ovo, i onda će sve biti u redu." Nema se čega bojati, sve je samo nečuveno i sad ćemo otvoriti ovu zgražanje. Dakle, što je to HTTP protokol i s čime se jede?
1.1 Klijent i poslužitelj
U svijetu nema čuda, a još više u svijetu programiranja i interneta! Shvatite ovo kao nepokolebljivu istinu. A ako program ne radi ili ne radi onako kako želite, najvjerojatnije je ili napisan pogrešno ili sadrži pogreške. Pa kako preglednik traži od poslužitelja da mu pošalje bilo što? Vrlo je 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 previše komplicirano, varate se. Osoba je tako konstruirana da jednostavno nije u stanju 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 pokretač razmjene podataka. Web poslužitelj nikada neće nikome ništa samo poslati, tako da nešto pošalje pregledniku - potreban mu je preglednik da to zatraži. Najjednostavniji HTTP zahtjev mogao bi izgledati ovako:
NABAVITE http: //www.php.net/ HTTP / 1.0rnrn
* GET (u prijevodu s engleskog znači "dobiti") - vrsta zahtjeva, vrsta zahtjeva može biti različita, na primjer POST, HEAD, PUT, DELETE (neke od njih ćemo razmotriti u nastavku).
* http://www.php.net/ - URI (adresa) s koje želimo dobiti barem neke informacije (naravno da se nadamo da ćemo dobiti neku HTML stranicu).
* HTTP / 1.0 - vrsta i verzija protokola koji ćemo koristiti u procesu komunikacije s poslužiteljem.
* rn - kraj retka, koji se mora ponoviti dvaput, zašto, postat će jasno malo kasnije.
Ovaj zahtjev možete vrlo lako ispuniti. Pokrenite program telnet.exe, unesite www.php.net kao host, navedite port 80 i jednostavno upišite ovaj upit pritiskom na Enter dvaput kao rnrn. Kao odgovor, dobit ćete HTML kod glavne stranice web stranice www.php.net.
1.3 Struktura upita
Pogledajmo od čega se sastoji HTTP zahtjev. Sve je dovoljno jednostavno. Za početak, HTTP zahtjev je smislen tekst. U čemu se sastoji u općem slučaju? Razmotrimo HTTP 1.0 protokol. tako :
Zahtjev - redak [Općenito - zaglavlje | Zahtjev - Zaglavlje | Entitet - zaglavlje] rn [Entitet - tijelo]
* Request-Line - redak zahtjeva
*
Format : "Zahtjev za metodu-URI HTTP-Verzijarn"
* Metoda - metoda koja će upravljati resursom Request-URI može biti GET, POST, PUT, DELETE ili HEAD.
* Request-URI je relativna ili apsolutna veza 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, zahtjev sa skupom varijabli a i b s odgovarajućim vrijednostima bit će poslan poslužitelju, a simbol "&" - ampersand služi kao razdjelnik između parametara.
* HTTP-Verzija - verzija HTTP protokola, u našem slučaju "HTTP / 1.0".
Izuzetno smo zainteresirani za metode GET i POST obrade. S metodom GET možete jednostavno proslijediti parametre skripti, a s metodom POST možete emulirati slanje obrasca.
Za metodu GET, Request-URI može izgledati ovako: "/index.html?param1=1¶m2=2".
* Općenito zaglavlje - Glavni dio zaglavlja.
Format:
Može imati samo dva parametra: Datum ili Pragma. Datum je srednje vrijeme po Greenwichu u formatu "Dan u tjednu, Dan u mjesecu Godina HH: MM: SS GMT", na primjer, "Uto, 15. studenog 1994. 08:12:31 GMT" je datum kada je zahtjev bio stvorio. Pragma može imati jednu vrijednost, bez predmemorije, koja onemogućuje predmemoriju stranica.
* Zaglavlje zahtjeva - dio zaglavlja koji opisuje zahtjev.
Zaglavlje zahtjeva može imati sljedeće parametre : Dopusti, Autorizacija, Od, Ako-Modificirano-Od, Preporučitelj, Korisnički agent.
U ovom poglavlju nećemo obrađivati parametar autorizacije jer se koristi za pristup privatnim resursima, što nije potrebno često. Možete samostalno proučiti formiranje zaglavlja za ovlašteni pristup na web stranici www.w3c.org.
* Dopusti - postavlja prihvatljive metode obrade.
Format: "Dopusti: GET | HEADn".
Parametar se zanemaruje kada se specificira POST metoda obrade u retku zahtjeva. Određuje prihvatljive metode za obradu zahtjeva. Proxy poslužitelji ne mijenjaju parametar Allow i on dolazi do poslužitelja nepromijenjen.
* Od - adresa e-pošte koja je poslala zahtjev.
Format: "Od: adderssrn".
Na primjer, "Od: [e-mail zaštićen]".
* If-Modified-Since - označava da zahtjev nije izmijenjen od tog i tog vremena.
Format: "If-Modified-Since: datern"
Koristi se samo za metodu GET obrade. Datum je u srednjem vremenu po Greenwichu u istom formatu kao i parametar Datum u Općem zaglavlju.
* Preporučitelj - apsolutna poveznica na stranicu s koje je pokrenut zahtjev, odnosno poveznica na stranicu s koje je korisnik otišao na našu.
Format: "Preporučitelj: urln".
Primjer: "Preporučitelj: www.host.ru/index.htmln".
* Korisnički agent - vrsta preglednika.
Na primjer: "Korisnički agent: Mozilla / 4.0n"
* Entity-Header - dio zaglavlja koji opisuje podatke entiteta-tijela.
U ovom dijelu zahtjeva postavljaju se parametri 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.
* Content-Encoding - Tip kodiranja podataka entiteta-tijela.
Format: "Kodiranje sadržaja: x-gzip | x-compress | drugi tip".
Primjer: "Kodiranje sadržaja: x-gzipn". Simbol "|" znači riječ "ili", odnosno ovo ili ono ili ono itd.
Drugi tip može ukazivati na način kodiranja podataka, na primjer, za POST metodu: "Content-Encoding: application / x-www-form-urlencodedn".
* Content-Length - broj bajtova poslanih tijelu entiteta. Vrijednost Content-Length ima potpuno drugačije značenje za podatke koji se šalju u MIME formatu, gdje djeluje kao parametar za opisivanje dijela podataka - "vanjski / tijelo entiteta". Važeći su cijeli brojevi od nule ili više.
Primjer: "Dužina sadržaja: 26457n".
* Content-Type - vrsta prenesenih podataka.
Na primjer: "Vrsta sadržaja: tekst / htmln".
* Istječe - vrijeme kada stranicu treba ukloniti iz predmemorije preglednika.
Format: "Ističe: datum". Format datuma sličan je formatu datuma za parametar Datum iz Općeg zaglavlja.
* Last-Modified - vrijeme posljednje izmjene prenesenih podataka.
Format: "Zadnja izmjena: datum". Format datuma sličan je formatu datuma za parametar Datum iz Općeg zaglavlja.
* Extention-header - dio zaglavlja koji može biti namijenjen, na primjer, za obradu od strane preglednika ili drugog programa koji prihvaća dokument. U ovom dijelu možete opisati svoje parametre u formatu "ParameterName: parametervaluen". Ovi parametri će biti zanemareni ako klijentski program ne zna kako ih rukovati.
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 da ćemo razumjeti na primjerima.
Zamislimo da moramo dobiti stranicu sa stranice prijenosom kolačića, inače ćemo jednostavno biti poslani kao nepozvani gosti, a štoviše, poznato je da je na ovu stranicu dopušten ulazak tek nakon što ste posjetili glavnu stranicu stranice .
2 GET metoda
Napišimo našu molbu.
UZMI 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 metodom GET. Polje Host označava da se ova stranica nalazi na poslužitelju www.site.ru, polje Referer označava da smo došli po vijesti s glavne stranice stranice, a polje Cookie označava da je takav i takav kolačić dodijeljen nas. Zašto su Host, Referer i Cookie toliko važni? Budući da obični programeri, kada stvaraju dinamičke stranice, provjeravaju ova polja koja se pojavljuju u skriptama (uključujući PHP) u obliku varijabli. Čemu služi? Kako bi npr. spriječili pljačku stranice, t.j. nije na njemu postavio program za automatsko preuzimanje, odnosno da bi osoba koja je ušla na stranicu uvijek na nju došla samo s glavne stranice itd.
Sada zamislimo da trebamo ispuniti polja obrasca na stranici i poslati zahtjev iz obrasca, neka ovaj obrazac ima dva polja: prijavu i lozinku (login i lozinku) - i, naravno, znamo prijavu i lozinku .
UZMI http: //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP / 1.0rn
Domaćin: www. mjesto. trčati
Referent: http://www.site.ru/index.htmlrn
Kolačić: prihod = 1rn
rn
Prijavite se s nama "Petya Vasechkin" Zašto bismo trebali napisati Petya% 20Vasechkin? To je zato što poslužitelj može prepoznati posebne znakove kao znakove novog parametra ili kraja zahtjeva itd. Stoga postoji algoritam za kodiranje naziva parametara i njihovih vrijednosti, kako bi se izbjegle neočekivane situacije u zahtjevu. Potpuni opis ovog algoritma možete pronaći ovdje, a PHP ima funkcije rawurlencode i rawurldecode za kodiranje i dekodiranje. Želim napomenuti da PHP sam dekodira ako su kodirani parametri preneseni u zahtjevu. Ovdje počinjem prvo poglavlje svog uvoda u HTTP protokol. U sljedećem poglavlju pogledat ćemo konstrukciju POST zahtjeva (u prijevodu s engleskog - "pošalji"), što će biti puno zanimljivije, jer upravo se ova vrsta zahtjeva koristi prilikom slanja podataka iz HTML obrazaca.
3. POST metoda.
U slučaju HTTP POST zahtjeva, postoje dvije opcije za prijenos polja iz HTML obrazaca, odnosno korištenje algoritama application / x-www-form-urlencoded i multipart / form-data. Razlike između ovih algoritama su vrlo značajne. Činjenica je da je prva vrsta algoritma stvorena davno, kada HTML jezik još nije pružao mogućnost prijenosa datoteka putem HTML obrazaca. Pa pogledajmo ove algoritme s primjerima.
3.1 Vrsta sadržaja: aplikacija / x-www-form-urlencoded.
Pišemo zahtjev sličan našem GET zahtjevu za prijenos prijave i lozinke, o čemu je bilo riječi u prethodnom poglavlju:
POST http: //www.site.ru/news.html HTTP / 1.0rn
Domaćin: www. mjesto. trčati
Referent: http://www.site.ru/index.htmlrn
Kolačić: prihod = 1rn
Sadržaj - Vrsta: aplikacija / 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 zauzeti podatkovno područje, koje je odvojeno od zaglavlja drugim redak feedom rn. Ali parametri koji su prethodno bili postavljeni u Request-URI za GET zahtjev sada su u tijelu entiteta. Vidi se da su formirane na isti način, samo ih treba napisati iza naslova. Želim napomenuti još jednu važnu točku, ništa ne sprječava da se istovremeno sa skupom parametara u tijelu entiteta stave parametri s različitim nazivima u Request-URI, na primjer:
POST http: //www.site.ru/news.html?type=user HTTP / 1.0rn
.....
rn
prijava = Petya% 20Vasechkin & lozinka = qq
3.2 Vrsta sadržaja: višedijelni / podaci obrasca
Čim je svijet interneta shvatio da bi bilo lijepo i slati datoteke putem obrazaca, konzorcij W3C pristupio je finalizaciji formata POST zahtjeva. U to vrijeme, MIME format (Višenamjenska proširenja internetske pošte) već je bio naširoko korišten, stoga smo, kako ne bismo ponovno izumili kotač, odlučili koristiti dio ovog formata poruke za kreiranje POST zahtjeva u HTTP protokolu.
Koje su glavne razlike između ovog formata i tipa application / x-www-form-urlencoded?
Glavna razlika je u tome što se entitet-tijelo sada može podijeliti na odjeljke koji su razdvojeni granicama. Ono što je najzanimljivije je da svaki odjeljak može imati svoj naslov koji opisuje podatke koji su u njemu pohranjeni, t.j. u jednom zahtjevu možete prenijeti podatke različitih vrsta (kao u pismu Mail, možete prenijeti datoteke zajedno s tekstom).
Pa krenimo. Razmotrimo ponovno isti primjer s prijenosom prijave i lozinke, ali sada u novom formatu.
POST http: //www.site.ru/news.html HTTP / 1.0rn
Domaćin: www. mjesto. trčati
Referent: http://www.site.ru/index.htmlrn
Kolačić: prihod = 1rn
Sadržaj - Duljina: 209rn
rn
- 1BEF0A57BE110FD467Arn
Sadržaj - Dispozicija: oblik - podaci; ime = "prijava" rn
rn
Petya Vasechkinrn
- 1BEF0A57BE110FD467Arn
Sadržaj - Dispozicija: oblik - podaci; ime = "lozinka" rn
rn
qqrn
- 1BEF0A57BE110FD467A - rn
Sada da shvatimo što je napisano. :-) Namjerno sam neke rn znakove označio masnim slovima kako se ne bi spojili s podacima. Ako pažljivo pogledate, možete vidjeti granično polje nakon Content-Type. Ovo polje postavlja separator odjeljka - obrub. Niz koji se sastoji od latiničnih slova i brojeva, kao i još nekih znakova (nažalost, ne sjećam se kojih) može se koristiti kao obrub. U tijelu zahtjeva na početak obruba dodaje se "-", a zahtjev završava obrubom kojemu se na kraju dodaju i znakovi "-". U našem zahtjevu postoje dva odjeljka, prvi opisuje polje za prijavu, a drugi opisuje polje lozinke. Content-Disposition (tip podataka u odjeljku) kaže da će to biti podaci iz obrasca, a naziv polja se postavlja u polje za naziv. Ovdje završava zaglavlje odjeljka, a zatim slijedi područje podataka odjeljka u koje se postavlja vrijednost polja (ne morate kodirati vrijednost!).
Želim vam skrenuti pozornost na činjenicu da ne morate koristiti Content-Length u zaglavljima odjeljka, ali je u zaglavlju zahtjeva potrebno i njegova vrijednost je veličina cijelog Entity-Body nakon drugog rn-a nakon sadržaja -Duljina: 209rn. Oni. Tijelo entiteta odvojeno je od naslova dodatnim redom (što se također može vidjeti u odjeljcima).
Sada napišimo zahtjev za prijenos datoteke.
POST http: //www.site.ru/postnews.html HTTP / 1.0rn
Domaćin: www. mjesto. trčati
Referent: http://www.site.ru/news.htmlrn
Kolačić: prihod = 1rn
Sadržaj - Vrsta: višedijelni / obrazac - podaci; granica = 1BEF0A57BE110FD467Arn
Sadržaj - Dužina: 491rn
rn
- 1BEF0A57BE110FD467Arn
Sadržaj - Dispozicija: oblik - podaci; name = "news_header" rn
rn
Primjer vijestirn
- 1BEF0A57BE110FD467Arn
Sadržaj - Dispozicija: oblik - podaci; naziv = "datoteka_vijesti"; naziv datoteke = "news.txt" rn
Sadržaj - Vrsta: aplikacija / oktet - streamrn
Sadržaj - Prijenos - Kodiranje: binaryrn
rn
I evo novosti,
koji se nalazi u datoteci vijesti... txtrn
- 1BEF0A57BE110FD467A - rn
U ovom primjeru, prvi odjeljak prosljeđuje naslov vijesti, a drugi odjeljak prosljeđuje datoteku news.txt. Pažljiva osoba vidjet će polja za naziv datoteke i Content-Type u drugom odjeljku. Polje naziva datoteke je naziv prenesene datoteke, a Content-Type je vrsta datoteke. Application/octet-stream označava da je ovo standardni tok podataka, a Content-Transfer-Encoding: binarni 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 upload 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 "ručno" formirate zahtjev, 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
image / tiff za tiff (koji se rijetko koristi, vrlo je prostran format)
U našem primjeru formira se zahtjev u kojem se prenosi tekstualna datoteka. Na isti način formira se zahtjev za prijenos binarne datoteke.
4. Postscript.
Mislim da o prijenosu zahtjeva na poslužitelj ne vrijedi detaljnije govoriti. Ovo je stvar čisto PHP tehnologije :-). Dovoljno je pažljivo pročitati odjeljak o funkcijama za rad s utičnicama, odnosno o funkcijama CURL modula u službenoj PHP dokumentaciji.
Iz navedenog se nadam da je sada jasno zašto se postavlja pitanje: "Kako mogu formirati POST zahtjev pomoću funkcije zaglavlja?" - besmisleno je. Funkcija zaglavlja (niz) dodaje unos samo u zaglavlje zahtjeva, a ne u tijelo zahtjeva.
| leđa |
