știri uptostart.ru. Jocuri. Instrucţiuni. Internet. Birou.
Aceasta și următoarele secțiuni vor acoperi pe scurt cum să creați aplicații web de bază folosind PHP. Ceea ce s-a discutat în secțiune clar nu este suficient pentru ca aplicația ta să comunice cu utilizatorul și să formuleze în funcție de acțiunile pe care le-a efectuat sau de parametrii introduși. Ce lipsește? Nu există suficiente cunoștințe despre cum să organizați introducerea datelor utilizatorului și transferul acestor date către server. Ei bine, ar trebui să aveți deja cunoștințe de bază despre cum să procesați programatic informațiile primite pe server.
Metode de solicitare HTTP și parametrii acestora
Orice aplicație web dinamică generează un răspuns utilizatorului în conformitate cu parametrii introduși de acesta sau cu acțiunile efectuate pe partea clientului. Contactarea serverului se reduce cel mai adesea la două tipuri de solicitări: folosind metoda GET sau metoda POST. Câteva cuvinte despre diferențele dintre aceste două tipuri de solicitări.
metoda GET:Parametrii sunt trecuți în antetul solicitării HTTP, deci sunt vizibili în linie de comandă, iar o astfel de solicitare poate fi salvată în marcaje. Deoarece lungimea totală a antetului este limitată, numărul și lungimea parametrilor trecuți folosind GET sunt de asemenea limitate.
Se crede că rezultatele mai multor cereri GET identice executate la rând ar trebui să fie aceleași.
Parametrii de solicitare sunt trecuți în corpul cererii HTTP, deci nu sunt prezenți pe linia de comandă. Numărul și dimensiunea parametrilor sunt nelimitate.
Se crede că rezultatele multiplelor solicitări POST identice pot returna valori diferite, deoarece pot modifica proprietățile obiectului țintă.
Metoda GET ar trebui utilizată pentru a prelua conținutul unei resurse de informații în funcție de parametri atunci când nu este nevoie de a face modificări la structurile de date ale resursei țintă și este logic să salvați cererea (URL) în marcaje. Metoda GET poate fi mai rapidă decât solicitările similare folosind metoda POST.
Metoda POST ar trebui utilizată atunci când trebuie să ascundeți parametrii trecuți serverului din URL. Această metodă ar trebui folosită și în cererile de modificări ale conținutului resursei țintă, trecând o descriere a acestor modificări în parametrii (în corpul cererii).
Calea către resursă?parameter1=value1¶meter2=value2&...
Dacă nu aveți un formular HTML special pentru completarea parametrilor, atunci puteți depana funcționarea aplicației dvs. PHP trecând parametrii de testare direct pe linia de comandă a browserului, de exemplu:
Http://site/php-samples/sql.php?sql=select * din d_staff
Pentru a accesa parametrii de solicitare din partea serverului, ar trebui să utilizați matrice globale $_GETŞi $_POST respectiv. Dacă aplicației dvs. nu îi pasă prin ce metodă este accesată, atunci ar trebui să utilizați o matrice $_CERERE, care combină datele matricelor $_GET și $_POST, de exemplu, astfel:
$sql = isset($_REQUEST["sql"]) ? $_REQUEST["sql"]: "";
În acest exemplu, programul determină dacă parametrul „sql” a fost trecut: dacă da, își atribuie valoarea variabilei corespunzătoare, iar dacă nu, îi atribuie o valoare goală.
Definirea parametrilor de solicitare HTTP prin formular HTML
Desigur, definirea manuală a parametrilor direct în linia de comandă a browserului nu este foarte convenabilă. Această metodă este potrivită pentru execuția programatică a solicitărilor HTTP atunci când aplicațiile web comunică între ele. Pentru a introduce și a efectua verificarea inițială a datelor din partea clientului, ar trebui să utilizați formulare HTML și . Mai jos este un exemplu cea mai simplă formă, cu care se introduce un parametru de text (valoare), care este ulterior transmis serverului ca parametru al metodei POST.
Atributul method al elementului formular specifică metoda care determină metoda de transmitere a datelor către server (get sau post). Atributul acțiune specifică fișier php , care va procesa cererea. Dacă handlerul ar trebui să fie fișierul curent, atunci nu este necesar să fie adăugat atributul de acțiune. Pentru toate elementele a căror valoare trebuie să fie transmisă ca parametru de solicitare HTTP, trebuie să definiți o valoare unică pentru atributul nume. Este valoarea atributului nume va fi indexîn tablourile $_GET, $_POST sau $_REQUEST (vezi exemplul de mai sus). Apăsând un buton depune trimite formularul cu toate valorile introduse către server.
Prima metodă de a efectua o solicitare PHP POST este utilizarea file_get_contents . A doua metodă va folosi fread în combinație cu alte câteva funcții. Ambele opțiuni folosesc funcția stream_context_create pentru a completa câmpurile de antet solicitate.
Explicația codului
Variabila $sPD conține datele de transferat. Trebuie să fie în format de șir de solicitare HTTP, așa că unele caractere speciale trebuie să fie codificate.
Atât în funcția file_get_contents, cât și în funcția fread avem doi parametri noi. Primul este use_include_path . Deoarece facem o solicitare HTTP, aceasta va fi falsă în ambele exemple. Când este setată la true pentru a citi o resursă locală, funcția va căuta fișierul la include_path .
Al doilea parametru este context, care este populat cu valoarea returnată a stream_context_create, care ia valoarea matricei $aHTTP.
Folosind file_get_contents pentru a face cereri POST
Pentru a trimite o solicitare POST folosind file_get_contents în PHP, trebuie să utilizați stream_context_create pentru a completa manual câmpurile de antet și a specifica ce „wrapper” va fi folosit - în în acest caz, HTTP:
$sURL = "http://brugbart.com/Examples/http-post.php"; // Adresa URL POST $sPD = "nume=Jacob&bench=150"; // Date POST $aHTTP = array("http" => // Wrapper care va fi folosit array("method" => "POST", // Metoda de solicitare // Anteturile de solicitare sunt setate sub "header" => "Conținut - tip: application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $contents = file_get_contents($sURL, false, $context); echo $conținut;
Folosind fread pentru a efectua cereri POST
Puteți utiliza funcția fread pentru a face solicitări POST. Următorul exemplu folosește stream_context_create pentru a compune anteturile de solicitare HTTP necesare:
$sURL = "http://brugbart.com/Examples/http-post.php"; // Adresa URL POST $sPD = "nume=Jacob&bench=150"; // Date POST $aHTTP = array("http" => // Wrapper care va fi folosit array("method" => "POST", // Request Method // Antetele cererii sunt setate sub "header" => "Conținut - tip: application/x-www-form-urlencoded”, „content” => $sPD)); $context = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $conținut = ""; în timp ce (!feof($mâner)) ( $conținut .= fread($mâner, 8192); ) fclose($mâner); echo $conținut;
Efectuarea cererilor GET cu PHP
Acum ne vom concentra pe utilizarea fread și file_get_contents pentru a descărca conținut de pe internet prin HTTP și HTTPS. Pentru a utiliza metodele descrise în acest articol, trebuie să activați opțiunea fopen wrappers. Pentru a face acest lucru, trebuie să setați parametrul allow_url_fopen la On în fișierul php.ini.
Efectuarea solicitărilor POST și GET în PHP este folosită pentru a vă conecta pe site-uri web, pentru a prelua conținutul paginii web sau pentru a verifica dacă există noi versiuni de aplicații. Vom discuta cum să faceți cereri HTTP simple.
Utilizarea fread pentru a descărca sau a primi fișiere prin Internet
Rețineți că citirea paginii web este limitată la porțiunea accesibilă a pachetului. Deci trebuie să utilizați funcția stream_get_contents ( similar cu file_get_contents) sau o buclă while pentru a citi conținutul în bucăți mai mici până când se ajunge la sfârșitul fișierului:
În acest caz de procesare a unei solicitări PHP POST, ultimul argument al funcției fread este egal cu dimensiunea fragmentului. În general, nu ar trebui să fie mai mare de 8192 ( 8*1024 ).
Ceea ce au în comun este că funcționează la fel. Din punct de vedere tehnic, nu există nicio diferență între ele. Dar există diferențe ideologice.
Voi vorbi despre ele în contextul PHP. Vă rugăm să rețineți că protocolul HTTP este indirect legat de PHP deoarece a fost creat pentru schimbul de pagini html și PHP pur și simplu extinde capacitățile ambelor.
Solicitarea GET este folosită pentru a primi date și POST este folosit pentru a trimite. (Amintiți-vă că din punct de vedere tehnic funcționează la fel).
Prin urmare, în contextul PHP, pe baza acestei ideologii, am făcut următoarele:
1. De fiecare dată când porniți PHP, matricele superglobale ($_GET, $_POST) sunt create implicit.
2. Dacă există un semn de întrebare (?) în șirul de interogare. Totul după ce este luat în considerare parametrii Cererea GET, acestea sunt prezentate în formatul "key"="valoare" iar caracterul ampersand (&) este folosit ca delimitator.
Exemplu:
GET /index.php?name=Andrey&surname=Galkin
Acesta este un șir de interogare, există 2 parametri. acești parametri vor intra în tabloul $_GET.
3. $_POST este completat într-un mod diferit. conținutul acestei matrice este completat din „anteturile cererii”. Adică dintr-un loc clar ascuns vederii. Browserul se ocupă de toate treburile creării unor astfel de anteturi. Deși uneori ceva este editat în titluri manual.
Cel mai adesea, o cerere de postare este utilizată în formulare (pentru a trimite date).
De exemplu, avem un formular de autentificare cu 2 câmpuri: autentificare și parolă.
Să ne imaginăm că folosim metoda GET. Apoi, la trimiterea formularului, vom merge la următoarea adresă /login.php?login=Andrey&password=123 Veți fi de acord că transmiterea unor astfel de informații în acest mod nu este deloc sigură. Oricine vă poate deschide browserul și, începând să introducă adresa site-ului, vă poate vedea parolele și login-urile din istoric.
Dar dacă am specifica metoda POST, am primi următoarea solicitare:
POST /login.php (login=Andrey&password=123) ceea ce este între paranteze ar fi ascuns și nu ar fi salvat în niciun fel în browser.
Pentru a rezuma:
GET este să obțineți o anumită pagină o anumită formă(triere, pagina curentă blog, bară de căutare etc.).
POST - pentru trimiterea de date care nu afectează afișarea paginii, în sensul că aceste date afectează doar rezultatul scriptului (autentificări, parole, numere de card de credit, mesaje etc.).
Și o altă veste bună este că pot fi combinate, de exemplu
POST /index.php?page=login (login=Andrey&password=123) Cred că am explicat deja suficient ce va veni din asta și ce parametri vor intra în ce matrice.
ÎN în ultima vreme Văd din ce în ce mai multe întrebări pe forumul principal PHPClub pe tema creării cererilor POST și GET, precum și întrebări pe tema: „Cum pot genera o solicitare POST folosind funcția de antet.” Cred că necesitatea de a puncta „i”-urile în utilizarea această tehnologie, deoarece programatorii începători pur și simplu nu înțeleg principiile web ca atare. Deci, să începem călătoria noastră prin lumea protocolului HTTP.
1. Protocolul HTTP. Introducere
Aș dori să clarific un mic lucru imediat.
Cuvântul teribil protocol nu este altceva decât un acord al multor oameni, doar la un moment bun oamenii au decis: „Să facem așa, și atunci totul va fi bine”. Nu este nimic de care să ne fie frică, totul este pur și simplu scandalos și acum vom dezvălui această rușine. Deci, ce este protocolul HTTP și pentru ce este folosit?
Nu există miracole în lume, și mai ales în lumea programării și a internetului!
Acceptă asta ca pe un adevăr de neclintit. Și, dacă programul nu funcționează sau nu funcționează așa cum se dorește, atunci, cel mai probabil, fie este scris incorect, fie conține erori. Deci, cum cere browserul serverului să-i trimită ceva?
Da, 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. Omul este conceput în așa fel încât pur și simplu nu este capabil să creeze ceva complex, altfel el însuși se va încurca în el :-) Deci, există un browser și există un server Web.
- Browserul este întotdeauna inițiatorul schimbului de date. Un server Web nu va trimite pur și simplu nimic nimănui, astfel încât să trimită ceva către browser - browserul trebuie să ceară asta.
- Cea mai simplă solicitare HTTP ar putea arăta astfel:
- GET http://www.php.net/ HTTP/1.0\r\n\r\n
\r\n este sfârșitul rândului, care trebuie repetat de două ori de ce va deveni clar puțin mai târziu.
Puteți efectua această solicitare foarte simplu. Rulați programul telnet.exe, introduceți www.php.net ca gazdă, specificați portul 80 și pur și simplu introduceți această solicitare apăsând Enter de două ori ca \r\n\r\n. Ca răspuns, veți primi cod HTML
pagina de start site-ul www.php.net.
- 1.3 Structura cererii Să vedem în ce constă o solicitare HTTP.
- Linia de solicitare[General-Header | Antet cerere | Entity-Header ]\r\n[ Entity-Body ]
- Linia de solicitare- 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 din urmă caz, serverului i se va trimite o solicitare cu un set de variabile a și b cu valorile corespunzătoare, iar semnul „&” - un ampersand - servește ca separator între parametri. Versiune HTTP
Totul este destul de simplu. Să începem cu faptul că o solicitare HTTP este un text complet semnificativ. În ce constă în cazul general? Vom lua în considerare protocolul HTTP 1.0. Aşa:
- 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 transmite pur și simplu parametri scriptului, iar cu metoda POST puteți emula trimiterea formularelor. Pentru metoda GET, Request-URI ar putea arăta astfel:
- „/index.html?param1=1¶m2=2”. General-Header
- partea principală a titlului.
Format: - Poate avea doar doi parametri: Data sau Pragma. Data - data Greenwich în formatul „Ziua săptămânii, Zi luna Anul HH:MM:SS GMT”, de exemplu, „Mar, 15 noiembrie 1994 08:12:31 GMT” - data creării cererii. Pragma poate avea o singură valoare fără cache, care dezactivează stocarea în cache a paginii.
Antetul cererii - parte a antetului care descrie cererea..
Request-Header poate avea următorii parametri: - Allow, Authorization, From, If-Modified-Since, Referer, User-AgentÎn acest capitol, nu vom lua în considerare parametrul Autorizare, deoarece este folosit pentru a accesa resurse private, care nu este necesar foarte des.
Puteți afla cum să creați singur un antet de acces autorizat la www.w3c.org.
Permite - - stabilește metode de procesare acceptabile. - Format: „Permite: GET | HEAD\n”. Parametrul este ignorat când se specifică metoda de procesare POST în Request-Line. Specifică metode acceptabile de procesare a cererilor.
Serverele proxy nu modifică parametrul Allow și ajunge la server neschimbat.
Din Adresa de e-mail care a trimis cererea. - Format: „De la: adresă\r\n”. De exemplu, „De la:
[email protected]
\r\n”. - Dacă-Modificat-De vreme ce- indică faptul că cererea nu a fost modificată de la un moment dat.
Format: „Dacă-Modificat-De la: data\r\n”
Folosit numai pentru metoda de procesare GET. Data este specificată în GMT în același format ca și pentru parametrul Data din Antetul General. - Referitor- 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 venit la a noastră.
Format: „Referitor: url\n”. - Exemplu: „Referitor: www.host.ru/index.html\n”. User-Agent
Această parte a cererii specifică parametrii care descriu corpul paginii. Entity-Header poate conține următorii parametri: Allow, Content-Coding, Content-Length, Content-Type, Expires, Last-Modified, extension-header. - Allow, Authorization, From, If-Modified-Since, Referer, User-Agent- un parametru similar cu Allow from General-Header.
- Codificarea conținutului- codificarea datelor tip Entity-Body.
Format: „Codificarea conținutului: x-gzip | x-compress | alt tip\n”.
Exemplu: „Codificarea conținutului: x-gzip\n”. Caracterul „|”. înseamnă cuvântul „sau”, adică asta sau aia sau aia etc.
Un alt tip poate indica modul în care datele sunt codificate, de exemplu, pentru metoda POST: „Content-Encoding: application/x-www-form-urlencoded\n”. - Conținut-Lungime- 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 descrierea unei părți a datelor - „external/entity-body”.
Numerele valide sunt numere întregi de la zero și mai sus. - Exemplu: „Lungimea conținutului: 26457\n”. Tip de conținut
- tipul datelor transmise. - De exemplu: „Content-Type: text/html\n”. Expiră
- Ora la care pagina ar trebui să fie eliminată din memoria cache a browserului. - Format: „Expiră: data\n”. Formatul de dată este același cu formatul de dată pentru parametrul Date din General-Header. Ultima modificare
- ora ultimei modificări a datelor transmise. - Format: „Ultima modificare: dată\n”. Formatul de dată este același cu formatul de dată pentru parametrul Date din General-Header. antetul extensiei
- o parte a antetului, care poate fi destinată, de exemplu, să fie procesată de un browser sau alt program care primește documentul. În această parte, puteți descrie parametrii dvs. în formatul „NumeParametru: valoare parametru\n”. Acești parametri vor fi ignorați dacă programul client nu știe cum să-i proceseze.
De exemplu: „Cookie: r=1\r\n” - setează cookie-uri bine-cunoscute 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? Desigur, vom înțelege cu exemple.
Să ne imaginăm că trebuie să obținem o pagină de pe site prin trecerea Cookie-urilor, altfel vom fi pur și simplu trimiși ca oaspeți neinvitați și, mai mult, se știe că aveți voie să accesați această pagină numai după ce ați vizitat pagina principală a site-ului. site-ul.
2 metoda GET
Să scriem cererea noastră.
GET http://www.site.ru/news.html HTTP/1.0\r\n
Gazdă: www.site.ru\r\n
Cookie: venit=1\r\n
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ă că ni s-a atribuit un astfel de cookie. De ce sunt atât de importante câmpurile Gazdă, Referer și Cookie? Pentru că programatorii normali, atunci când creează site-uri dinamice, verifică câmpurile de date care apar în scripturi (inclusiv PHP) sub formă de variabile. Pentru ce este asta? Pentru a preveni, de exemplu, jefuirea site-ului, i.e.
nu au setat un program pe el pentru descărcare automată, sau pentru ca o persoană care vizitează site-ul 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ă fie două câmpuri în acest formular: autentificare și parolă (autentificare și parolă) - și, desigur, cunoaștem autentificarea si parola.
GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Gazdă: www.site.ru\r\n
Cookie: venit=1\r\n
Referer: http://www.site.ru/index.html\r\n Login-ul nostru este „Petya Vasechkin” De ce ar trebui să scriem Petya%20Vasechkin? Acest lucru se datorează faptului că caracterele speciale pot fi recunoscute de către server ca semne ale prezenței unui nou parametru sau ale sfârșitului unei cereri etc. Prin urmare, există un algoritm pentru codificarea numelor parametrilor și a valorilor acestora pentru a evita situațiile de eroare în cerere. Descriere completă
ale acestui algoritm pot fi găsite, iar în PHP există funcții rawurlencode și rawurldecode pentru codare și respectiv decodare. Aș dori să notez că PHP face decodarea în sine dacă parametrii codificați au fost trecuți în cerere. Aceasta încheie primul capitol al cunoașterii mele cu protocolul HTTP. În capitolul următor ne vom uita la solicitări de construire precum POST (tradus din engleză ca „trimite”), care vor fi mult mai interesante, deoarece Acesta este tipul de solicitare care este folosit la trimiterea datelor din formulare HTML.
3. Metoda POST.
3.1 Tip de conținut: application/x-www-form-urlencoded.
Scriem o solicitare similară cu solicitarea noastră GET de a transfera autentificarea și parola, despre care a fost discutată în capitolul anterior:
GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Gazdă: www.site.ru\r\n
Tip de conținut: application/x-www-form-urlencoded\r\n
Lungimea conținutului: 35\r\n
Cookie: venit=1\r\n
Aici vedem un exemplu de utilizare a câmpurilor de antet Content-Type și Content-Length. Lungimea conținutului indică câți octeți va ocupa zona de date, care este separată de antet printr-o altă întrerupere de linie \r\n. Dar parametrii care au fost plasați anterior în Request-URI pentru o solicitare GET sunt acum în Entity-Body. Se vede că sunt formate exact în același mod, trebuie doar să le scrieți după titlu. Vreau să subliniez încă un lucru punct important
, nimic nu împiedică, concomitent cu setul de parametri din Entity-Body, plasarea parametrilor cu alte nume în Request-URI, de exemplu:
.....
Cookie: venit=1\r\n
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n
login=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ă fișiere prin formulare, consorțiul W3C a început să perfecționeze formatul de solicitare POST. Până atunci, formatul MIME (Multipurpose Internet Mail Extensions - extensii de protocol multifuncționale pentru generarea de mesaje Mail) era deja utilizat pe scară largă, prin urmare, pentru a nu reinventa roata, am decis să folosim o parte din acest format de generare a mesajelor pentru a crea Solicitări POST în protocolul HTTP.
Care sunt principalele diferențe dintre acest format și tipul application/x-www-form-urlencoded?
Principala diferență este că Entity-Body poate fi acum împărțit în secțiuni, care sunt separate prin granițe (limită). Cel mai interesant este că fiecare secțiune poate avea propriul antet pentru a descrie datele care sunt stocate în ea, de exemplu.
într-o singură solicitare puteți transfera date de diferite tipuri (ca într-o scrisoare Mail, puteți transfera fișiere în același timp cu text).
GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Gazdă: www.site.ru\r\n
Deci, să începem. Să luăm din nou același exemplu cu transferul de autentificare și parolă, dar acum într-un nou format.
Cookie: venit=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Lungimea conținutului: 209\r\n
--1BEF0A57BE110FD467A Lungimea conținutului: 209\r\n
Lungimea conținutului: 209\r\n
\r\n Lungimea conținutului: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Lungimea conținutului: 209\r\n
Conținut-Dispoziție: formular-date; nume = "login" Lungimea conținutului: 209\r\n
Lungimea conținutului: 209\r\n
Petia Vasechkin Lungimea conținutului: 209\r\n
Conținut-Dispoziție: formular-date; nume="parolă" Lungimea conținutului: 209\r\n
Acum să înțelegem ce este scris. :-) Am evidențiat în mod special câteva caractere \r\n cu caractere aldine pentru a nu se îmbina cu datele. Dacă vă uitați cu atenție, veți observa câmpul de delimitare după Content-Type. Acest câmp specifică separatorul de secțiuni - chenar. Un șir format din litere și numere latine, precum și alte simboluri (din păcate, nu-mi amintesc care altele) poate fi folosit ca chenar. În corpul cererii, „--” este adăugat la începutul graniței, iar cererea se termină cu o graniță, la care se adaugă și caracterele „--” la sfârșit. Solicitarea noastră are două secțiuni, prima descrie câmpul de conectare, iar a doua descrie câmpul pentru parolă.
Content-Disposition (tipul de date din secțiune) spune că acestea vor fi date din formular, iar câmpul de nume specifică numele câmpului. Aici se termină antetul secțiunii și ceea ce urmează este zona de date a secțiunii în care este plasată valoarea câmpului (nu este nevoie să codificați valoarea!).
Aș dori să vă atrag atenția asupra faptului că nu trebuie să utilizați Content-Length în anteturile de secțiune, dar în antetul cererii ar trebui, iar valoarea acesteia este dimensiunea întregului Entity-Body, care apare după al doilea \ r\n după lungimea conținutului: 209\ r\n. Aceste. Entity-Body este separat de antet printr-o întrerupere suplimentară de linie (care poate fi văzută și în secțiuni).
Acum să scriem o solicitare pentru a transfera un fișier.
GET http://www.site.ru/news.html HTTP/1.0\r\n
POST http://www.site.ru/postnews.html HTTP/1.0\r\n
Gazdă: www.site.ru\r\n
Referer: http://www.site.ru/news.html\r\n
Tip de conținut: date multiple/form-date; limită=1BEF0A57BE110FD467A\r\n
Cookie: venit=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Lungimea conținutului: 209\r\n
Lungimea conținutului: 491\r\n Lungimea conținutului: 209\r\n
Lungimea conținutului: 209\r\n
Conținut-Dispoziție: formular-date; name="news_header" Lungimea conținutului: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Lungimea conținutului: 209\r\n
Stiri de exemplu Lungimea conținutului: 209\r\n
Conținut-Dispoziție: formular-date; name="file_news"; Lungimea conținutului: 209\r\n
filename="news.txt" Lungimea conținutului: 209\r\n
Lungimea conținutului: 209\r\n
Tip de conținut: aplicație/flux-octet Lungimea conținutului: 209\r\n
Conținut-Dispoziție: formular-date; nume="parolă" Lungimea conținutului: 209\r\n
Conținut-Transfer-Codificare: binar
Un punct foarte important. Cele mai multe script-uri CGI sunt scrise de oameni inteligenți, așa că le place să verifice tipul fișierului primit, care se află în Content-Type. Pentru ce? Cel mai adesea, încărcarea fișierelor pe site-uri web este folosită pentru a primi imagini de la 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 un gif sau jpeg, ignoră acest fișier. Prin urmare, atunci când creați o solicitare „manual”, aveți grijă de valoarea Content-Type, astfel încât să fie cel mai apropiată de formatul fișierului transferat.
În exemplul nostru, este generată o cerere în care fișier text. O solicitare pentru transferul unui fișier binar este generată în același mod.
4. Post-scriptum.
Cred că nu merită să vorbim în detaliu despre trimiterea cererilor către server. Aceasta este o chestiune de tehnologie pur RHP :-). 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 este: „Cum pot genera o solicitare POST folosind funcția antet?” - fără sens.
Funcția header(string) adaugă o intrare numai la antetul cererii, dar nu și la corpul solicitării.
Există un alt tip de solicitare - Content-Type: multipart/mixed, sper că după ce ați citit acest articol veți înțelege ușor acest tip. Îl poți studia în detaliu
Această postare este un răspuns 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, de ce au fost inventate și cum să le folosiți în conformitate cu REST.
HTTPDeci, care este unul dintre principalele protocoale ale Internetului? Voi trimite pedanții la RFC2616, iar restul le voi spune uman :)
Acest protocol descrie interacțiunea dintre două computere (client și server), construită pe baza unor mesaje numite cerere (Solicitare) și răspuns (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 pornire.
Liniile de început pentru cerere și răspuns au formate diferite - ne interesează doar linia de început a cererii, care arată astfel: METODA URI HTTP/ ,
VERSIUNE Unde METHOD este metoda de solicitare HTTP, URI este identificatorul resursei, VERSION este versiunea protocolului (pentruîn acest moment
Anteturile sunt o colecție de perechi nume-valoare separate prin două puncte. Antetele transmit diverse informații de serviciu: codificarea mesajelor, numele și versiunea browserului, adresa de la care a venit clientul (Referrer) și așa mai departe.
Corpul mesajului este datele efective transmise. În răspuns, datele transmise sunt de obicei 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ă, nu există niciun corp de mesaj în cerere.
Exemplu de interacțiune HTTP
Să ne uităm la un exemplu.Cerere:
GET /index.php HTTP/1.1 Gazdă: example.com Agent utilizator: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Conexiune: închide
Prima linie este linia de interogare, 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; charset=utf-8 Lungimea conținutului: 1234 Conexiune: închidere... PAGINA HTML ÎNSĂȘI...
Resurse și Metode
Să revenim la linia de pornire a cererii și să ne amintim că aceasta 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 și un obiect abstract („/blogs/webdev/” - puncte la dezvoltarea blocului „Web””, mai degrabă decât pe un anumit fișier).Tipul de cerere HTTP (numit și metoda HTTP) îi spune serverului ce acțiune dorim să facem asupra resursei. Inițial (la începutul anilor 90) se presupunea că clientul își putea dori doar un singur lucru de la o resursă - să o primească, dar acum folosind protocolul HTTP poți crea postări, edita un profil, șterge mesaje și multe altele. Și aceste acțiuni sunt greu de combinat cu termenul „chitanță”.
Pentru a diferenția acțiunile de resurse la nivelul metodelor HTTP, au fost inventate următoarele opțiuni:
- GET - obținerea unei resurse
- POST - crearea de resurse
- PUT - actualizare de resurse
- DELETE - ștergerea resurselor
REST intră în joc
REST (REpresentational State Transfer) este un termen introdus în 2000 de Roy Fielding, unul dintre dezvoltatorii protocolului HTTP, ca denumirea unui grup de principii pentru construirea de aplicații web. În general, REST acoperă o zonă mai largă decât HTTP - poate fi folosit și în alte rețele cu alte protocoale. REST descrie principiile interacțiunii dintre client și server, pe baza conceptelor de „resursă” și „verb” (poate fi înțeles ca subiect și predicat). În cazul HTTP, resursa este identificată prin URI, iar verbul este metoda HTTP.REST sugerează abandonarea utilizării aceluiași URI pentru resurse diferite (adică adresele a două articole diferite precum /index.php?article_id=10 și /index.php?article_id=20 - aceasta nu este o modalitate REST) și folosind diferite metode HTTP pentru diferite acțiuni. Adică, o aplicație web scrisă folosind abordarea REST va șterge o resursă atunci când o accesează cu metoda HTTP DELETE (desigur, asta nu înseamnă că este necesar să se acorde posibilitatea de a șterge totul și toți, 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 înainte. 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 - o șterge.
Probleme?
Da, există o mică problemă cu utilizarea REST în practică. Această problemă se numește HTML.Solicitările PUT/DELETE pot fi trimise folosind XMLHttpRequest, contactând serverul manual (să zicem, prin curl sau chiar prin telnet), dar nu puteți face un formular HTML care trimite o cerere PUT/DELETE cu drepturi depline.
Chestia 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 a lucra normal cu alte metode, trebuie să le imitați artificial. De exemplu, în Rack (mecanismul pe baza căruia Ruby interacționează cu serverul web; Rails, Merb și alte cadre Ruby sunt realizate folosind Rack), puteți adăuga un câmp ascuns la formular cu numele „_method” și specificați numele metodei ca valoare (de exemplu, „PUT”) - în acest caz, va fi trimisă o solicitare POST, dar Rack va putea pretinde că a primit un PUT mai degrabă decât un POST.
