Această postare este răspunsul la o întrebare pusă într-unul dintre articolele mele.

În acest articol, vreau să vă spun care sunt metodele HTTP GET / POST / PUT / DELETE și altele, pentru ce au fost inventate și cum să le folosiți în conformitate cu REST.

HTTP

Deci, care este exact unul dintre protocoalele principale ale Internetului? Voi trimite pedanții la RFC2616, iar restul îi voi spune ca un om :)

Acest protocol descrie comunicarea între două computere (client și server), pe baza mesajelor numite Cerere și Răspuns. Fiecare mesaj este format din trei părți: o linie de început, anteturi și un corp. În acest caz, este necesară doar linia de start.

Liniile de început pentru cerere și răspuns au un format diferit - ne interesează doar linia de început a cererii, care arată astfel:

METODA URI HTTP / VERSIUNE ,

Acolo unde METHOD este doar metoda de solicitare HTTP, URI este identificatorul resursei, VERSION este versiunea protocolului (versiunea 1.1 este relevantă în prezent).

Anteturile sunt o colecție de perechi nume-valoare, separate prin două puncte. În anteturi sunt transmise diverse informații de serviciu: codificarea mesajului, numele și versiunea browserului, adresa de la care a venit clientul (Referrer) și așa mai departe.

Corpul mesajului este, de fapt, datele transmise. În răspuns, datele transmise, de regulă, sunt pagina html pe care browser-ul a solicitat-o, iar în cerere, de exemplu, în corpul mesajului, se transmite conținutul fișierelor încărcate pe server. Dar, de regulă, corpul mesajului nu este deloc inclus în cerere.

Exemplu de comunicare HTTP

Să ne uităm la un exemplu.

Anchetă:
GET /index.php HTTP / 1.1 Gazdă: example.com User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko / 2008050509 Firefox / 3.0b5 Accept: text / html Conexiune: close
Prima linie este linia de solicitare, restul sunt anteturi; corpul mesajului lipsește

Răspuns:
HTTP / 1.0 200 OK Server: nginx / 0.6.31 Content-Language: ru Content-Type: text / html; set de caractere = utf-8 Lungimea conținutului: 1234 Conexiune: închidere ... PAGINA HTML ÎNSĂȘI ...

Resurse și metode

Să revenim la șirul de interogare de început și să ne amintim că acesta conține un astfel de parametru precum URI. Aceasta înseamnă Uniform Resource Identifier - un identificator uniform de resursă. O resursă este, de regulă, un fișier de pe server (un exemplu de URI în acest caz este „/styles.css”), dar, în general, o resursă poate fi un obiect abstract („/ blogs / webdev /” - indică blocul „Dezvoltare web”, și nu pentru un anumit fișier).

Tipul de cerere HTTP (numit și metoda HTTP) îi spune serverului ce acțiune dorim să facem cu resursa. Inițial (la începutul anilor 90) se presupunea că clientul poate dori un singur lucru de la resursă - să o obțină, dar acum, folosind protocolul HTTP, puteți crea postări, edita profilul, șterge mesaje și multe altele. Și aceste acțiuni sunt greu de combinat cu termenul „primire”.

Pentru a diferenția acțiunile cu resurse la nivelul metodelor HTTP, au fost inventate următoarele opțiuni:

• GET - obținerea unei resurse
• POST - crearea unei resurse
• PUT - actualizare de resurse
• DELETE - ștergerea unei resurse

Acordați atenție faptului că specificația HTTP nu obligă serverul să înțeleagă toate metodele (care de fapt sunt mult mai mult de 4) - este necesar doar GET și, de asemenea, nu spune serverului ce ar trebui să facă atunci când primește o solicitare cu o anumită metodă. Aceasta înseamnă că serverul răspunde la o solicitare DELETE /index.php HTTP / 1.1 nu este obligat săștergeți pagina index.php de pe server, la fel ca în cererea GET /index.php HTTP / 1.1 nu este obligat să returnează pagina index.php la tine, o poate șterge ca :)

REST intră în joc

REST (REpresentational State Transfer) - acest termen a fost inventat în 2000 de Roy Fielding - unul dintre dezvoltatorii protocolului HTTP - ca denumire pentru un grup de principii pentru construirea de aplicații web. În general, REST acoperă o zonă mai largă decât HTTP - poate fi folosit pe alte rețele cu alte protocoale. REST descrie principiile interacțiunii client-server, pe baza conceptelor de „resursă” și „verb” (le puteți înțelege ca subiect și predicat). În cazul HTTP, resursa este definită de URI-ul său, iar verbul este metoda HTTP.

REST propune să renunțe la utilizarea aceluiași URI pentru resurse diferite (adică adresele a două articole diferite precum /index.php?article_id=10 și /index.php?article_id=20 nu sunt o modalitate REST) ​​și să folosească diferite metode HTTP pentru diferite acțiuni. Adică, o aplicație web scrisă folosind abordarea REST va șterge o resursă atunci când o accesați cu metoda HTTP DELETE (desigur, asta nu înseamnă că ar trebui să puteți șterge totul și totul, dar orice cererea de ștergere a aplicației trebuie să utilizeze metoda HTTP DELETE).

REST oferă programatorilor posibilitatea de a scrie aplicații web standardizate și puțin mai frumoase decât oricând. Folosind REST, URI-ul pentru adăugarea unui nou utilizator nu va fi /user.php?action=create (metoda GET / POST), ci pur și simplu /user.php (strict metoda POST).

Ca rezultat, combinând specificația HTTP existentă și abordarea REST, diferite metode HTTP au în sfârșit sens. GET - returnează o resursă, POST - creează una nouă, PUT - actualizează una existentă, DELETE - șterge.

Probleme?

Da, există o mică problemă cu aplicarea REST în practică. Această problemă se numește HTML.

Solicitările PUT/DELETE pot fi trimise prin XMLHttpRequest, contactând serverul „manual” (să zicem, prin curl sau chiar prin telnet), dar nu puteți face un formular HTML trimițând o cerere PUT/DELETE completă.

Ideea este că specificația HTML nu vă permite să creați formulare care trimit date altfel decât prin GET sau POST. Prin urmare, pentru funcționarea normală cu alte metode, trebuie să le imitați artificial. De exemplu, în Rack (mecanismul prin care Ruby interacționează cu serverul web; Rails, Merb și alte cadre Ruby sunt realizate folosind Rack), puteți adăuga un câmp ascuns numit „_method” la un formular și să specificați numele metoda ca valoare (de exemplu, „PUT”) - în acest caz, va fi trimisă o solicitare POST, dar Rack va putea pretinde că a primit un PUT, nu un POST.

În prezent, doar două metode HTTP sunt cele mai frecvent utilizate: GET și POST. Dar s-a dovedit că și printre acești doi „pini” dezvoltatorii web reușesc să se piardă. Există o explicație pentru aceasta: ambele metode pot fi folosite pentru a obține același rezultat. Dar trebuie amintit că aplicarea greșită a oricăreia dintre metode poate duce la consecințe dezastruoase, inclusiv sarcini mari pe canal și găuri de securitate.

Pentru a evita acest lucru, este suficient să înțelegeți mai detaliat scopul și diferențele acestor metode.

Dacă vă aprofundați în sensul numelor metodelor, multe vor deveni clare. GET (din engleză pentru a primi), i.e. ar trebui folosit pentru a interoga datele. POST (din engleză send by mail) - îl folosim pentru a trimite date către server. Totul pare a fi extrem de simplu și de înțeles. Dar cine vrea să dezvolte site-uri puțin mai complicate decât un site de cărți de vizită cu un singur formular de feedback, este mai bine să cunoască problema mai bine.

Cereri HTTP sigure și nesigure

Specificația HTTP 1.1 introduce două concepte: o cerere sigură și o cerere nesigură, sau mai precis, o metodă.

Metodele sigure sunt metode care pot solicita doar informații. Nu pot modifica resursa solicitată, nu pot duce la rezultate nedorite pentru utilizator, alte persoane sau server. Exemple de cele sigure sunt solicitarea codului HTML al unei pagini web sau al unei imagini. Metodele sigure sunt HEAD și GET.

Nota

În realitate, meșterii, desigur, pot face rău cu cererile GET. De exemplu, bucle de interogare.

Interogările nesigure, după cum toată lumea a ghicit deja, pot duce la consecințe negative dacă sunt reutilizate. Astfel de solicitări pot modifica conținutul resursei care este accesată. Exemple de astfel de solicitări: trimitere de mesaje, înregistrare, plăți online. Metodele nesigure sunt POST, PUT, DELETE.

Metode idempotente

Idempotenta este o proprietate a metodelor care, cu apeluri repetate multiple, va returna același rezultat, cu excepția cazului în care informațiile sunt învechite. Aceasta înseamnă că atunci când accesează aceeași adresă URL, toți utilizatorii vor vedea aceeași pagină web, imagine, videoclip etc. Metodele GET, PUT, DELETE au această proprietate.

Acum să aruncăm o privire mai atentă asupra metodelor GET și POST în sine: să compunem un scurt „rezumat” pentru fiecare.

OBȚINE

• conceput pentru a primi date de la server;
• corpul cererii este gol;
• sunt procesate pe partea serverului mai rapid și cu un consum mai mic de resurse server datorită unui corp de cerere gol;
• transferul de variabile are loc în bara de adrese (așa îl vede utilizatorul, tehnic datele sunt transferate în linia de interogare) și, prin urmare, informațiile despre variabile și valorile acestora sunt vizibile (datele nu sunt protejate);
• capabil să transfere o cantitate mică de date către server: există restricții privind lungimea URL-ului, care depinde de browser, de exemplu IE6 = 2Kb. Acesta este numărul pe care dezvoltatorii Yahoo! recomandă să-l vizeze;
• poate transmite doar caractere ASCII;
• o astfel de solicitare poate fi copiată, salvată (de exemplu, în marcaje);
• cererea poate fi stocată în cache (aceasta poate fi controlată);
• cererile condiționate și parțiale sunt disponibile pentru a reduce și mai mult sarcina pe canal și pe server;
• nu întrerupe conexiunea HTTP (când modul keepAlive este activat pe server).

POST

• conceput pentru a trimite date către server;
• transferul de date are loc în corpul de solicitare;
• procesarea pe partea serverului este mai lentă și „mai grea” decât GET, deoarece, pe lângă anteturi, trebuie să analizați corpul cererii;
• capabil să transfere cantități mari de date;
• capabil să transfere fișiere;
• pagina generată prin metoda POST nu poate fi marcată;
• întrerupe conexiunea HTTP;
• pentru a transfera chiar și o cantitate foarte mică de informații, majoritatea browserelor trimit cel puțin două pachete TCP: antetul și apoi corpul cererii.

Se pare că aceste două metode nu sunt atât de asemănătoare. Utilizarea cutare sau cutare ar trebui să fie determinată de sarcina în cauză și nu de faptul că GET este utilizat în mod implicit sau este mai ușor de lucrat. GET este cu siguranță o opțiune mai bună în majoritatea cazurilor, mai ales când construiești AJAX-uri rapide, dar nu uita de dezavantajele acesteia. Pentru mine, am făcut un algoritm-notă simplă cu privire la alegerea metodei.

1. Protocolul HTTP. Introducere

Vreau doar să clarific un lucru mic. Cuvântul teribil protocol nu este altceva decât un acord al multor oameni, doar la un moment bun oamenii au decis: „Să facem asta și atunci totul va fi bine”. Nu este nimic de care să ne fie frică, totul este pur și simplu scandalos și acum vom deschide acest ultraj. Deci, ce este acest protocol HTTP și cu ce se mănâncă?

1.1 Client și Server

Nu există miracole în lume și cu atât mai mult în lumea programării și a internetului! Înțelege asta ca pe un adevăr de neclintit. Și, dacă programul nu funcționează sau nu funcționează așa cum doriți, atunci, cel mai probabil, fie este scris greșit, fie conține erori. Deci, cum cere browserul serverului să-i trimită ceva? E foarte simplu! Trebuie doar să te relaxezi puțin și să începi să te bucuri de proces :-)

1.2. Se scrie prima noastră solicitare HTTP

Dacă crezi că totul este prea complicat, atunci te înșeli. O persoană este atât de construită încât pur și simplu nu este capabilă să creeze ceva complex, altfel el însuși va fi confuz în asta :-) Deci, există un browser și există un server web. Browserul este întotdeauna inițiatorul schimbului de date. Un server web nu va trimite niciodată nimic nimănui, astfel încât să trimită ceva către browser - are nevoie de browser pentru a-l cere. Cea mai simplă solicitare HTTP ar putea arăta astfel:

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

* GET (tradus din engleză înseamnă „obține”) – tipul de solicitare, tipul de solicitare poate fi diferit, de exemplu POST, HEAD, PUT, DELETE (vom lua în considerare câteva dintre ele mai jos).
* http://www.php.net/ - URI (adresă) de la care dorim să obținem măcar câteva informații (desigur că sperăm să obținem o pagină HTML).
* HTTP / 1.0 - tipul și versiunea protocolului pe care îl vom folosi în procesul de comunicare cu serverul.
* rn - sfârșitul liniei, care trebuie repetat de două ori, de ce, va deveni clar puțin mai târziu.

Puteți îndeplini această solicitare foarte ușor. Rulați programul telnet.exe, introduceți www.php.net ca gazdă, specificați portul 80 și introduceți pur și simplu această interogare apăsând Enter de două ori ca rnrn. Ca răspuns, veți primi codul HTML al paginii principale a site-ului www.php.net.

1.3 Structura interogării

Să aruncăm o privire la ce constă o solicitare HTTP. Totul este destul de simplu. Pentru început, o solicitare HTTP este un text semnificativ. În ce constă în cazul general? Să luăm în considerare protocolul HTTP 1.0. asa de :

Solicitare - Linie [General - Antet | Solicitare - Antet | Entitate - Antet] rn [Entitate - Corp]

* Request-Line - linie de solicitare
*

Format : „Metodă Solicitare-URI HTTP-Versionrn”
* Metoda - metoda care va gestiona resursa Request-URI poate fi GET, POST, PUT, DELETE sau HEAD.
* Request-URI este un link relativ sau absolut către o pagină cu un set de parametri, de exemplu, /index.html sau http://www.myhost.ru/index.html sau /index.html?a=1&b= qq. În acest ultim caz, o solicitare cu un set de variabile a și b cu valori corespunzătoare va fi trimisă către server, iar simbolul „&” - ampersand servește ca separator între parametri.
* HTTP-Version - versiunea protocolului HTTP, în cazul nostru „HTTP / 1.0”.

Suntem extrem de interesați de metodele de procesare GET și POST. Cu metoda GET, puteți pur și simplu să transmiteți parametri la script, iar cu metoda POST, puteți emula o trimitere a unui formular.

Pentru metoda GET, Request-URI ar putea arăta astfel: „/index.html?param1=1¶m2=2”.

* General-Header - Partea principală a antetului.
Format:
Poate avea doar doi parametri: Data sau Pragma. Data - Greenwich Mean Time în formatul „Ziua săptămânii, ziua lunii An HH: MM: SS GMT”, de exemplu, „Marți, 15 noiembrie 1994 08:12:31 GMT” - data solicitării. Pragma poate avea o singură valoare, no-cache, care dezactivează stocarea în cache a paginii.

* Request-Header - parte a antetului care descrie cererea.

Request-Header poate avea următorii parametri : Permite, Autorizare, De la, Dacă-Modificat-Deoarece, Referer, User-Agent.
Nu vom acoperi parametrul Autorizare în acest capitol, deoarece este folosit pentru a accesa resurse private, ceea ce nu este necesar foarte des. Puteți studia independent formarea antetului pentru acces autorizat pe site-ul www.w3c.org.

* Permite - setează metode de procesare acceptabile.
Format: „Permite: GET | HEADn”.
Parametrul este ignorat atunci când se specifică metoda de procesare POST în Request-Line. Specifică metodele acceptabile pentru procesarea unei cereri. Proxy-urile serverului nu modifică parametrul Allow și ajunge pe server neschimbat.

* De la - adresa de e-mail care a trimis solicitarea.
Format: „De la: aderssrn”.
De exemplu, „De la: [email protected]".

* If-Modified-Since - indică faptul că cererea nu a fost modificată de la un moment dat.
Format: „Dacă-Modificat-Din: datern”
Folosit numai pentru metoda de procesare GET. Data este în Greenwich Mean Time în același format ca parametrul Data din Antetul general.

* Referrer - un link absolut către pagina de pe care a fost inițiată cererea, adică un link către pagina de pe care utilizatorul a mers la a noastră.
Format: „Referitor: urln”.
Exemplu: „Referitor: www.host.ru/index.htmln”.
* User-Agent - tip browser.
De exemplu: „User-Agent: Mozilla / 4.0n”

* Entity-Header - parte a antetului care descrie datele Entity-Body.
În această parte a cererii, sunt setați parametri care descriu corpul paginii. Entity-Header poate conține următorii parametri: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extensie-header.

* Allow - un parametru similar cu Allow from General-Header.

* Codificarea conținutului - Tipul de codificare a datelor Entitate-Corp.
Format: „Codificarea conținutului: x-gzip | x-compress | alt tip”.
Exemplu: „Codificarea conținutului: x-gzipn”. Simbolul „|” înseamnă cuvântul „sau”, adică asta sau aia sau aia etc.
Un alt tip poate indica o modalitate de codificare a datelor, de exemplu, pentru metoda POST: „Content-Encoding: application / x-www-form-urlencodedn”.

* Content-Length - numărul de octeți trimiși către Entity-Body. Valoarea Content-Length are o semnificație complet diferită pentru datele trimise în format MIME, unde acționează ca un parametru pentru a descrie o bucată de date - „external / entity-body”. Numerele întregi de la zero sau mai multe sunt valide.
Exemplu: „Lungimea conținutului: 26457n”.

* Content-Type - tipul de date transmise.
De exemplu: „Content-Type: text / htmln”.

* Expiră - Ora la care pagina ar trebui să fie eliminată din memoria cache a browserului.
Format: „Expiră: data”. Formatul datei este similar cu formatul datei pentru parametrul Date din Antetul General.

* Last-Modified - ora ultimei modificări a datelor trimise.
Format: „Ultima modificare: data”. Formatul datei este similar cu formatul datei pentru parametrul Date din Antetul General.

* Extention-header - parte a antetului care poate fi destinată, de exemplu, procesării de către browser sau alt program care acceptă documentul. În această parte, puteți descrie parametrii dvs. în formatul „ParameterName: parametervaluen”. Acești parametri vor fi ignorați dacă programul client nu știe cum să îi gestioneze.
De exemplu: „Cookie: r = 1rn” - setează cookie-urile binecunoscute pentru pagină.

Și acum, după asemenea cuvinte groaznice, să încercăm să ne liniștim puțin și să înțelegem de ce avem nevoie? În mod firesc, vom înțelege prin exemple.

Să ne imaginăm că trebuie să obținem o pagină de pe site prin transferul Cookie-urilor, altfel vom fi pur și simplu trimiși ca oaspeți neinvitați și, mai mult, se știe că această pagină are voie să intre doar după ce ați vizitat pagina principală a site-ului .

2 metoda GET

Să scriem cererea noastră.

OBȚINE http:
Gazdă: www. site-ul. fugi

Cookie: venit = 1rn
rn

Această solicitare ne spune că dorim să obținem conținutul paginii de la http://www.site.ru/news.html folosind metoda GET. Câmpul Gazdă indică faptul că această pagină se află pe serverul www.site.ru, câmpul Referer indică că am venit pentru știri de pe pagina principală a site-ului, iar câmpul Cookie indică faptul că un astfel de cookie i-a fost atribuit ne. De ce sunt atât de importante gazdă, referitor și cookie? Pentru că programatorii normali, atunci când creează site-uri dinamice, verifică aceste câmpuri care apar în scripturi (inclusiv PHP) sub formă de variabile. Pentru ce este? Pentru a preveni, de exemplu, jefuirea site-ului, i.e. nu a setat un program de descărcare automată pe acesta, sau astfel încât o persoană care a intrat pe site să ajungă întotdeauna la el doar din pagina principală etc.

Acum să ne imaginăm că trebuie să completăm câmpurile formularului din pagină și să trimitem o solicitare din formular, să lăsăm acest formular să aibă două câmpuri: autentificare și parolă (login și parolă) - și, bineînțeles, cunoaștem autentificarea și parola .

OBȚINE http: //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP / 1.0rn
Gazdă: www. site-ul. fugi
Referer: http://www.site.ru/index.htmlrn
Cookie: venit = 1rn
rn

Conectați-vă cu noi „Petya Vasechkin” De ce ar trebui să scriem Petya% 20Vasechkin? Acest lucru se datorează faptului că caracterele speciale pot fi recunoscute de server ca semne ale unui nou parametru sau sfârșitul unei cereri etc. Prin urmare, există un algoritm de codificare a numelor parametrilor și a valorilor acestora, pentru a evita situațiile neașteptate în cerere. O descriere completă a acestui algoritm poate fi găsită aici, iar PHP are funcții rawurlencode și rawurldecode pentru codare și, respectiv, decodare. Vreau să observ că PHP se decodifică singur dacă parametrii codificați au fost transmisi în cerere. Aici încep primul capitol al introducerii mele în protocolul HTTP. În capitolul următor, ne vom uita la construcția cererilor POST (în traducere din engleză - „trimite”), care va fi mult mai interesantă, deoarece acest tip de solicitare este folosit la trimiterea datelor din formulare HTML.

3. Metoda POST.

În cazul unei solicitări HTTP POST, există două opțiuni pentru transferul câmpurilor din formularele HTML și anume, folosind algoritmii aplicație / x-www-form-urlencoded și multipart / form-data. Diferențele dintre acești algoritmi sunt foarte semnificative. Cert este că primul tip de algoritm a fost creat cu mult timp în urmă, când limbajul HTML nu prevedea încă posibilitatea de a transfera fișiere prin formulare HTML. Deci, să aruncăm o privire la acești algoritmi cu exemple.

3.1 Tip de conținut: aplicație / x-www-form-urlencoded.

Scriem o solicitare similară cu solicitarea noastră GET pentru transferul unui login și al unei parole, despre care a fost discutată în capitolul anterior:

POSTĂ http: //www.site.ru/news.html HTTP / 1.0rn
Gazdă: www. site-ul. fugi
Referer: http://www.site.ru/index.htmlrn
Cookie: venit = 1rn
Conținut - Tip: cerere / x - www - formular - urlencodedrn
Continut - Lungime: 35rn
rn

Aici vedem un exemplu de utilizare a câmpurilor de antet Content-Type și Content-Length. Content-Length spune câți octeți va ocupa zona de date, care este separată de antet printr-un alt line feed rn. Dar parametrii care au fost plasați anterior în Request-URI pentru o cerere GET sunt acum în Entity-Body. Se vede că sunt formate la fel, trebuie doar să le scrieți după titlu. Mai vreau să remarc un punct important, nimic nu împiedică, concomitent cu setul de parametri din Entity-Body, să pună parametri cu nume diferite în Request-URI, de exemplu:

POSTĂ http: //www.site.ru/news.html?type=user HTTP / 1.0rn
.....
rn
autentificare = Petya% 20Vasechkin & parola = qq

3.2 Content-Type: multipart / form-data

De îndată ce lumea internetului și-a dat seama că ar fi bine să trimită și fișiere prin formulare, consorțiul W3C a preluat finalizarea formatului de solicitare POST. Până atunci, formatul MIME (Multipurpose Internet Mail Extensions) era deja utilizat pe scară largă, prin urmare, pentru a nu reinventa roata, am decis să folosim o parte din acest format de mesaj pentru a crea cereri POST în protocolul HTTP.

Care sunt principalele diferențe dintre acest format și tipul aplicație / x-www-form-urlencoded?

Principala diferență este că Entitatea-Corpul poate fi acum împărțită în secțiuni, care sunt separate prin granițe. Cel mai interesant este că fiecare secțiune poate avea propriul titlu pentru a descrie datele care sunt stocate în ea, adică. într-o singură solicitare, puteți transfera date de diferite tipuri (ca într-o scrisoare Mail, puteți transfera fișiere împreună cu textul).

Asadar, haideti sa începem. Luați în considerare din nou același exemplu cu transferul numelui de utilizator și al parolei, dar acum într-un nou format.

POSTĂ http: //www.site.ru/news.html HTTP / 1.0rn
Gazdă: www. site-ul. fugi
Referer: http://www.site.ru/index.htmlrn
Cookie: venit = 1rn

Conținut - Lungime: 209rn
rn
- 1BEF0A57BE110FD467Arn
Conținut - Dispoziție: formă - date; nume = "login" rn
rn
Petya Vasechkinrn
- 1BEF0A57BE110FD467Arn
Conținut - Dispoziție: formă - date; nume = „parolă” rn
rn
qqrn
- 1BEF0A57BE110FD467A - rn

Acum să înțelegem ce este scris. :-) Am marcat în mod deliberat câteva caractere rn cu caractere aldine, astfel încât să nu se îmbine cu datele. Privind cu atenție, puteți vedea câmpul de delimitare după Tipul de conținut. Acest câmp setează separatorul de secțiuni - chenar. Un șir format din litere și cifre latine, precum și alte caractere (din păcate, nu-mi amintesc care dintre ele) poate fi folosit ca chenar. În corpul cererii se adaugă un „-” la începutul chenarului, iar cererea se termină cu un chenar, la care se adaugă și caracterele „-” la sfârșit. Există două secțiuni în cererea noastră, prima descrie câmpul de conectare, iar a doua descrie câmpul pentru parolă. Content-Disposition (tipul de date în secțiune) spune că acestea vor fi date din formular, iar numele câmpului este setat în câmpul de nume. Aici se termină antetul secțiunii și apoi urmează zona de date ale secțiunii, în care este plasată valoarea câmpului (nu trebuie să codificați valoarea!).

Vreau să vă atrag atenția asupra faptului că nu trebuie să utilizați Content-Length în anteturile secțiunii, dar în antetul cererii este necesar și valoarea acesteia este dimensiunea întregului Entity-Body după al doilea rn care urmează Conținut -Lungime: 209rn. Acestea. Corpul-entitate este separat de titlu printr-un flux suplimentar de linie (care poate fi văzut și în secțiuni).

Acum să scriem o solicitare de transfer al fișierului.

POSTĂ http: //www.site.ru/postnews.html HTTP / 1.0rn
Gazdă: www. site-ul. fugi
Referer: http://www.site.ru/news.htmlrn
Cookie: venit = 1rn
Continut - Tip: multipart / formular - date; limita = 1BEF0A57BE110FD467Arn
Conținut - Lungime: 491rn
rn
- 1BEF0A57BE110FD467Arn
Conținut - Dispoziție: formă - date; name = "news_header" rn
rn
Exemplu de știri
- 1BEF0A57BE110FD467Arn
Conținut - Dispoziție: formă - date; nume = "fișier_știri"; nume fișier = "news.txt" rn
Conținut - Tip: aplicație / octet - streamrn
Conținut - Transfer - Codificare: binaryrn
rn
Și iată știrile, care se află în dosarul de știri... txtrn
- 1BEF0A57BE110FD467A - rn

În acest exemplu, prima secțiune redirecționează titlul știrilor, iar a doua secțiune redirecționează fișierul news.txt. Persoana atentă va vedea numele fișierului și câmpurile Tip de conținut în a doua secțiune. Câmpul nume de fișier este numele fișierului încărcat, iar tipul de conținut este tipul fișierului. Application / octet-stream indică faptul că acesta este un flux de date standard, iar Content-Transfer-Encoding: binary indică faptul că acestea sunt date binare, necodificate în niciun fel.

Un punct foarte important. Majoritatea scripturilor CGI sunt scrise de oameni inteligenți, așa că le place să verifice tipul fișierului primit, care se află în Tipul conținut. Pentru ce? Cel mai adesea, încărcarea fișierelor pe site-uri este folosită pentru a primi imagini de la un vizitator. Deci, browserul însuși încearcă să determine ce fel de fișier dorește să trimită vizitatorul și inserează tipul de conținut corespunzător în cerere. Scriptul îl verifică la primire și, de exemplu, dacă nu este gif sau jpeg, ignoră acest fișier. Prin urmare, atunci când formați „manual” o solicitare, aveți grijă de valoarea Content-Type, astfel încât să fie cel mai apropiată de formatul fișierului transferat.

Imagine / gif pentru gif
imagine / jpeg pentru jpeg
imagine / png pentru png
imagine / tiff pentru tiff (care este rar folosit, este un format foarte încăpător)

În exemplul nostru, se formează o cerere în care este transferat un fișier text. În același mod, se formează o cerere pentru a transfera un fișier binar.

4. Post-scriptum.

Cred că nu merită să vorbim în detaliu despre transmiterea cererilor către server. Aceasta este o chestiune de tehnologie pur PHP :-). Este suficient să citiți cu atenție secțiunea despre funcțiile pentru lucrul cu socket-uri, sau despre funcțiile modulului CURL din documentația oficială PHP.

Din cele de mai sus, sper că acum este clar de ce întrebarea: „Cum pot forma o solicitare POST folosind funcția de antet?” - este lipsit de sens. Funcția antet (șir) adaugă o intrare numai la antetul cererii, nu la corpul solicitării.

Înapoi

Da, da, toată lumea a învățat odată ceva. Singurul lucru care îi distinge pe oameni în această privință este că învățăturile sunt ușoare pentru cineva, în timp ce alții nu își pot da seama de esența problemei timp de multe luni. Astăzi vom vorbi despre solicitările POST și GET în HTML \ PHP.

Cererile POST și GET în sine (denumite în continuare simple cereri) au fost de mult înrădăcinate în toate resursele de pe Internet. Dacă dintr-o dată există o alternativă la aceste tehnologii, atunci probabil că nu va fi curând și, probabil, nu este necesar. Pentru că solicitările noastre îndeplinesc complet sarcina de a schimba date între paginile de internet.

Să ne uităm mai întâi la o solicitare GET. Să creăm un fișier index.php cu un cod html standard și, de asemenea, să plasăm un formular pe el, să fie un formular de comandă de produs.

Aici acordăm atenție etichetei formă... Are doi parametri acțiuneși metodă... Primul este responsabil pentru adresa paginii către care ne vom transfera datele, al doilea este responsabil pentru metoda prin care aceste date vor fi transferate. În interiorul acestei etichete este descris setul de date pe care dorim să le transferăm. Numele sunt atribuite datelor (parametrul Nume). De asemenea, este necesară introducerea tipului Trimite, care este butonul pe care se face clic pentru a trimite date.

Să ne salvăm fișierul și să-l deschidem într-un browser.
Calea paginii noastre în browser este „... / index.php”. Pe pagina însăși, vedem două câmpuri de introducere și un buton. Să adăugăm ceva în câmpurile noastre și să facem clic pe butonul „Comandă”. Pagina noastră a fost actualizată. Să aruncăm o privire la adresa sa: „… / index.php? OrderName = Test & count = 12”. (Am tastat cuvântul „Test” în al doilea „12” din primul câmp). După cum putem vedea, adresa paginii s-a schimbat ușor. Faptul este că transferul parametrilor cu o solicitare GET se realizează prin alocarea acestora la linia de adresă a paginii. Parametrii sunt separați de adresa principală prin „?”, iar parametrii diferiți prin „&”. Structura parametrilor este următoarea: parameter_name = valoare... Numele parametrului se va potrivi cu valoarea atributului nume din câmpul de intrare.
Hai să edităm puțin codul paginii:

> >

Acum să facem clic din nou pe butonul „Comandă”. După cum vedem, pagina a fost actualizată, dar câmpurile noastre au rămas completate. Acest lucru se datorează faptului că am specificat o valoare implicită pentru câmpurile noastre. Mai mult, aceste valori sunt parametrul GET primit. După cum putem vedea în codul PHP, parametrii GET sunt o matrice cu un index de șir egal cu numele parametrului. Dacă acum ne jucăm cu adresa site-ului și schimbăm valorile parametrilor din ea și apăsăm butonul „Enter”, vom observa din nou imaginea cu reîmprospătarea paginii și completând formularul nostru.

Este evident că este greșit (și nu este sigur) să trimiți date secrete sau de serviciu într-o solicitare GET. Este mai bine să îl folosiți pentru a transfera, de exemplu, id-ul știrii, care ar trebui luat de la bază sau numele paginii care ar trebui afișată.

O cerere POST este o altă problemă. Funcționează în același mod, dar nu stochează parametrii în bara de adrese. Să ne schimbăm forma:

$ _POST [„numecomandă”]?> > $ _POST [„număr”]?> >

După cum puteți vedea, însă nu s-au schimbat multe! Să deschidem pagina noastră, să punem ceva în câmpuri și să apăsăm butonul „Comandă”. Totul a funcționat la fel, însă (totuși), după cum vedem în linia de interogare, adresa „... / index.php” se etalează fără niciun fel de parametri. Astfel, ne cam „ascundem” datele de privirile indiscrete. Desigur, conceptul a fost ascuns, mai degrabă arbitrar, deoarece aceste date pot fi încă interceptate, dar asta e altă poveste. Să adăugăm parametrii „… / index.php? OrderName = Trololo & count = 100” la adresa noastră și apăsăm „Enter”. După cum vedem, pagina a fost încărcată, dar deși parametrii au fost trecuți, câmpurile erau goale. Acest lucru sugerează că, în ciuda similitudinii mari, aceste tipuri de solicitări nu se suprapun în niciun fel, iar dacă este nevoie, merită să scrieți un handler pentru fiecare tip de cerere separat.

Cred că este suficient. Elementele de bază ale întrebării, cred, sunt descrise cu capul.

Si inca putin… Nu uitați de verificarea parametrilor trecuți. Dacă știți sigur că parametrul trebuie să fie un număr, atunci întrerupeți toate încercările de a transfera o valoare nenumerică etc.

Poate ați observat că pe majoritatea site-urilor puteți vedea următoarele adrese:

Http: //site/index.php? Blog = 2

Aici, chiar și fără să cunoașteți php, puteți ghici că ne referim la fișier index.php Dar puțini oameni știu ce urmează după semnul întrebării. Este destul de simplu: ? blog = 2 aceasta este declarația variabilei globale „$ _GET [” blog „]” cu valoarea „2”. Astfel, trec scriptului o variabilă care este responsabilă de afișarea informațiilor din baza de date. Să scriem un mic script în care vei vedea clar totul:

if (isset ($ _ GET [„blog”])) (
echo $ _GET [„blog”];
}
?>

Folosim instrucțiunea de condiție dacă () deoarece condiția este următoarea linie:

Substanță ($ _ GET [„blog”])

isset () vă permite să aflați dacă variabila care este specificată între paranteze există, adică condiția pe care am descris-o în cod sună astfel: Dacă variabila $ _GET ["blog"] există, atunci afișați conținutul această variabilă pe ecran. Iată ce sa întâmplat:

Cred că este clar Se creează o variabilă globală $ _GET cu identificatorul pe care l-am declarat în bara de adrese ( în acest caz cu identificatorul „blog”)

Acum vreau să clarific un punct. Să presupunem că trebuie să declarăm două variabile, cum facem asta? Prima variabilă este declarată după semnul întrebării "?" A doua variabilă este declarată după un astfel de „&” ( Sincer să fiu, nu știu care este acest semn), iată un exemplu de declarare a trei variabile:

Http: //site/index.php? A = 1 & b = 2 & c = 3

Iată codul de ieșire:

if (isset ($ _ GET ["a"]) AND isset ($ _ GET ["b"]) AND isset ($ _ GET ["c"])) (
echo $ _GET ["a"]. "
";
echo $ _GET ["b"]. "
";
echo $ _GET ["c"]. "
";
}
?>

Condiția este așa:

Dacă există o variabilă globală $ _GET ["a"] și o variabilă globală $ _GET ["b"] și o variabilă globală $ _GET ["c"] atunci afișați-le, iată rezultatul:

Forme

Înainte să ajungem la postîntrebări, trebuie să înțelegeți ce sunt formele? De ce este necesar? Deoarece variabila globală $ _POST [""] este creată prin intermediul formularelor. Ce este un formular? Acestea sunt câmpuri pentru introducerea unui fel de informații de către utilizator. Câmpurile sunt pe o singură linie, câmpuri mari, există și butoane radio, casete de validare. Să ordonăm totul în ordine...

Formularul este o etichetă:

elemente de formă

Formularul are atribute, le voi enumera pe cele mai comune:

Să creăm un formular:

elemente de formă

Ca fișier handler, am pus fișierul test.php deoarece în ea scriu exemple pentru tine. Am setat metoda de trimitere a mesajelor deoarece aceste metode sunt folosite în 99,9% din cazuri. Am dat și formei noastre un nume - formă

Acum să ne scufundăm în lumea elementelor de formă. Primul lucru pe care trebuie să-l înțelegeți este că aproape toate elementele sunt etichete. singura diferență este în atribut tip la aceste etichete. Permiteți-mi să enumerez elementele de formular utilizate:

Sunt sigur că ați văzut astfel de câmpuri de mai multe ori, așa că aici, așa cum se spune: „fără comentarii”

Acum să punem împreună un scurt chestionar de instruire cu care vom lucra în continuare. Sarcina noastră este să compunem un mic chestionar care să ne spună numele persoanei care a completat, sexul, din ce țară este, culoarea lui preferată și un câmp de text în care utilizatorul poate adăuga ceva despre el însuși. asta am facut:

Numele tău Prenume Patronimic:

Genul tau:
M
F

Din ce tara esti

Rusia
Alta tara

Culoare(e) preferată(e):

Negru:
Roșu:
Alb:
Un alt:

Despre mine:

Rețineți că aproape fiecare etichetă are un atribut valoare, pentru ce este? Înregistrează datele pe care urmează să le transferați pe o altă pagină. Sper sa fie clar

Acum, dacă rulăm acest cod într-un browser, vom vedea următoarele:

Am folosit atributul pentru formular acțiune cu sensul test.php asta înseamnă, după cum am spus, datele din formular vor fi trecute în fișierul test.php.

Solicitare POST

Acum să scriem cod php care ne va permite să vedem informațiile pe care le-am introdus. Unde sunt stocate datele? În cazul solicitării get, datele noastre au fost stocate în variabila globală $ _GET [""]. Când se face o cerere de postare, datele vor fi în variabila globală $ _POST [""]. Între paranteze pătrate, trebuie să scrieți identificatorul, ca și în cazul variabilei globale get. Întrebarea este, de unde pot obține acest identificator? De aceea avem nevoie de atributul nume pe elementele formularului! Aceste nume sunt cele care servesc drept cheie pentru noi în postarea matricei globale. Ei bine, să începem să descriem scriptul:

dacă (isset ($ _ POST [„trimite”)) (
echo "Nume:". $ _ POST ["fio"]. "
";
echo „Sex:”. $ _ POST [„sex”]. „
";
echo „Țara de reședință:”. $ _ POST [„oraș”]. ”
";

Echo „Culoare(e) preferată(e):
";
echo $ _POST ["culoare_1"]. "
";
echo $ _POST ["culoare_2"]. "
";
echo $ _POST ["culoare_3"]. "
";
echo $ _POST ["culoare_4"]. "
";
echo "Despre mine:". $ _ POST ["despre"]. "


";
}
?>

Condiția if pe care am scris-o spune: Dacă există o variabilă globală $ _POST ["submit"], atunci afișăm datele pe ecran. Această variabilă globală este creată dacă am dat clic pe butonul de trimitere, motiv pentru care în acest exemplu avem nevoie de atributul name din buton. S-ar putea să vă întrebați de ce atributul nume este opțional pentru buton? Este destul de simplu. De obicei, programatorul nu urmărește apăsarea butonului, ci urmărește datele trimise. Pentru funcționarea corectă, de exemplu, a formularelor de contact, este necesar să urmăriți nu apăsarea unui buton, ci corectitudinea informațiilor introduse și să aflați dacă aceste informații au fost introduse. În exemplul nostru, nu am verificat datele trimise, ci pur și simplu am urmărit clicul butonului, pentru a simplifica exemplul... Iată ce am primit:

Concluzie

Ei bine, astăzi am analizat două metode de transfer de date între scripturi, precum și galopurile s-au familiarizat cu formularele. Sper din tot sufletul că aceste informații vă vor fi utile măcar undeva. Dacă aveți întrebări sau gânduri, scrieți comentarii. Succes, am totul pentru azi!

PS: Vrei ca jocurile pe calculator să devină și mai realiste? Directx 11 pentru Windows 7 poate fi descărcat gratuit pe Windows în! Bucurați-vă de o grafică grozavă!

Top articole similare