Ce sunt anteturile HTTP? Teoria generala. Generarea cererilor HTTP
Vă prezentăm atenției o descriere a principalelor aspecte ale protocolului HTTP - protocol de rețea, de la începutul anilor 90 până în prezent, permițând browserului dvs. să încarce pagini web. Acest articol este scris pentru cei care abia încep să lucreze retele de calculatoareși dezvoltă aplicații de rețea și cărora le este greu să citească singuri specificațiile oficiale.
HTTP- un protocol de transfer de date utilizat pe scară largă, destinat inițial transferului de documente hipertext (adică documente care pot conține link-uri care permit navigarea către alte documente).
Abrevierea HTTP reprezintă Protocolul de transfer hipertext, „protocol de transfer hipertext”. Conform specificației OSI, HTTP este un protocol de aplicație (superior, al 7-lea). Curent activat acest moment versiunea protocolului, HTTP 1.1, este descrisă în specificația RFC 2616.
Protocolul HTTP implică utilizarea unei structuri de transfer de date client-server. Aplicația client generează o cerere și o trimite către server, după care aplicația server software procesează această solicitare, generează un răspuns și îl trimite înapoi clientului. După care aplicație client poate continua să trimită alte solicitări, care vor fi procesate în același mod.
O sarcină care este rezolvată în mod tradițional folosind protocolul HTTP este schimbul de date între aplicație utilizator care accesează resurse web (de obicei un browser web) și un server web. În prezent, datorită protocolului HTTP operează World Wide Web.
HTTP este adesea folosit ca protocol de transfer de informații pentru alte protocoale. nivelul de aplicare precum SOAP, XML-RPC și WebDAV. În acest caz, se spune că protocolul HTTP este folosit ca „transport”.
API-uri ale multor produse software implică, de asemenea, utilizarea HTTP pentru transferul de date - datele în sine pot fi în orice format, de exemplu, XML sau JSON.
De obicei, transferul de date HTTP se realizează prin conexiuni TCP/IP. În acest caz, software-ul server utilizează de obicei portul TCP 80 (și, dacă portul nu este specificat în mod explicit, atunci software-ul client utilizează de obicei portul 80 în mod implicit pentru deschiderea conexiunilor HTTP), deși poate folosi oricare altul.
Cum se trimite o solicitare HTTP?
Cel mai simplu mod de a înțelege protocolul HTTP este să încercați să accesați manual o resursă web. Imaginează-ți că ești browser și ai un utilizator care își dorește foarte mult să citească articole de Anatoly Alizar.Să presupunem că a intrat bara de adresa ca urmare a:
Http://alizar.habrahabr.ru/
În consecință, tu, ca browser web, acum trebuie să te conectezi la serverul web de la alizar.habrahabr.ru.
Pentru aceasta puteți folosi orice utilitate adecvată Linie de comanda. De exemplu, telnet:
Telnet alizar.habrahabr.ru 80
Permiteți-mi să clarific imediat că, dacă vă răzgândiți brusc, apăsați Ctrl + „]” și apoi introduceți - acest lucru vă va permite să închideți conexiunea HTTP. Pe lângă telnet, puteți încerca nc (sau ncat) - în funcție de gusturi.
După ce vă conectați la server, trebuie să trimiteți o solicitare HTTP. Acest lucru, apropo, este foarte ușor - cererile HTTP pot consta doar din două linii.
Pentru a genera o cerere HTTP, trebuie să compuneți o linie de pornire și, de asemenea, să setați cel puțin un antet - acesta este antetul Host, care este obligatoriu și trebuie să fie prezent în fiecare solicitare. Faptul este că conversia unui nume de domeniu la o adresă IP se realizează pe partea clientului și, în consecință, atunci când deschideți o conexiune TCP, atunci server la distanta nu are nicio informație despre care adresă exactă a fost folosită pentru conexiune: ar putea fi, de exemplu, adresa alizar.habrahabr.ru, habrahabr.ru sau m.habrahabr.ru - și în toate aceste cazuri răspunsul poate fi diferit . Cu toate acestea, de fapt conexiune retea in toate cazurile se deschide cu nodul 212.24.43.44, si chiar daca initial la deschiderea conexiunii nu a fost specificata aceasta adresa IP, ci unele Numele domeniului, atunci serverul nu este informat în niciun fel despre acest lucru - și de aceea această adresă trebuie trecută în antetul Host.
Linia de cerere de pornire (inițială) pentru HTTP 1.1 este compusă conform următoarei scheme:
De exemplu (o astfel de linie de pornire poate indica faptul că pagina principală a site-ului este solicitată):
Și, desigur, nu uitați că orice tehnologie devine mult mai simplă și mai clară atunci când începeți să o utilizați.
Mult succes si invatare fructuoasa!
Etichete: Adăugați etichete
HTTP (HyperText Transfer Protocol) a fost dezvoltat ca bază La nivel mondial Web.
Protocolul HTTP funcționează după cum urmează: programul client stabilește o conexiune TCP cu serverul ( Cameră standard port-80) și îi emite o solicitare HTTP. Serverul procesează această solicitare și emite un răspuns HTTP către client.
Structura cererii HTTP
O solicitare HTTP constă dintr-un antet de cerere și un corp de cerere, separate printr-o linie goală. Corpul cererii poate lipsi.
Antetul cererii este format din linia principală (prima) a cererii și liniile ulterioare care clarifică cererea în linia principală. Este posibil să lipsească și rândurile ulterioare.
Interogarea pe linia principală constă din trei părți, separate prin spații:
Metodă(cu alte cuvinte, comanda HTTP):
OBȚINE- cerere document. Metoda cea mai des folosită; în HTTP/0.9, spun ei, era singurul.
CAP- cerere titlu document. Diferă de GET prin faptul că este returnat doar antetul cererii cu informații despre document. Documentul în sine nu este emis.
POST- această metodă este folosită pentru a transfera date către scripturi CGI. Datele în sine apar în rândurile ulterioare ale cererii sub formă de parametri.
A PUNE- plasați documentul pe server. Din câte știu eu, este rar folosit. O cerere cu această metodă are un corp în care este transmis documentul în sine.
Resursă- acesta este calea spre fisier specific pe serverul pe care clientul dorește să-l primească (sau plasează - pentru metoda PUT). Dacă resursa este pur și simplu un fișier de citit, serverul trebuie să îl returneze în corpul răspunsului pentru această solicitare. Dacă aceasta este calea către un script CGI, atunci serverul rulează scriptul și returnează rezultatul execuției acestuia. Apropo, datorită acestei unificări de resurse, clientul este practic indiferent la ceea ce reprezintă pe server.
Versiunea protocolului-versiunea protocolului HTTP cu care funcționează programul client.
Deci, o cerere HTTP simplă ar putea arăta astfel:
Aceasta solicită fișierul rădăcină din directorul rădăcină al serverului web.
Rânduri după linia principală cererile au urmatorul format:
Parametru: valoare.
Așa sunt setați parametrii de solicitare. Acest lucru este opțional; toate liniile de după linia de interogare principală pot lipsi; în acest caz, serverul acceptă valoarea lor implicit sau pe baza rezultatelor solicitării anterioare (când lucrează în modul Keep-Alive).
Voi enumera câțiva dintre cei mai des utilizați parametrii de solicitare HTTP:
Conexiune(conexiune) - poate lua valorile Keep-Alive and close. Keep-Alive înseamnă că după emiterea acestui document, conexiunea la server nu este întreruptă și pot fi emise mai multe solicitări. Majoritatea browserelor funcționează în modul Keep-Alive, deoarece vă permite să „descărcați” o pagină html și imagini pentru aceasta într-o singură conexiune la server. Odată setat, modul Keep-Alive este menținut până la prima eroare sau până la următoarea solicitare Connection: close este specificată în mod explicit.
close ("închidere") - conexiunea este închisă după ce răspunde la această solicitare.
Agent utilizator- valoarea este „codul” browserului, de exemplu:
Mozilla/4.0 (compatibil; MSIE 5.0; Windows 95; DigExt)
Accept- o listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru un anumit browser, de exemplu pentru IE5 al meu:
Accept: imagine/gif, imagine/x-xbitmap, imagine/jpeg, imagine/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Acest lucru este evident necesar pentru cazul în care serverul poate scoate același document în formate diferite.
Valoarea acestui parametru este folosită în principal de scripturile CGI pentru a genera un răspuns adaptat pentru un anumit browser.
Referitor- URL de la care ați ajuns la această resursă.
Gazdă- numele gazdei de la care se solicită resursa. Util dacă serverul are mai multe servere virtuale sub aceeași adresă IP. În acest caz, numele server virtual determinat de acest domeniu.
Accept-Limba- limbaj suportat. Semnificativ pentru un server care poate servi același document în versiuni lingvistice diferite.
Format de răspuns HTTP
Formatul răspunsului este foarte asemănător cu formatul cererii: are, de asemenea, un antet și un corp separate printr-o linie goală.
Antetul constă, de asemenea, dintr-o linie principală și linii de parametri, dar formatul liniei principale este diferit de cel al antetului cererii.
Șirul de interogare principal este format din 3 câmpuri separate prin spații:
Versiunea protocolului- similar cu parametrul de cerere corespunzător.
Cod de eroare- denumirea de cod a „succesului” cererii. Codul 200 înseamnă „totul este normal” (OK).
Descrierea verbală a erorii- „descifrarea” codului anterior. De exemplu, pentru 200 este OK, pentru 500 - Server intern Eroare.
Cei mai comuni parametri de răspuns http:
Conexiune- similar cu parametrul de cerere corespunzător.
Dacă serverul nu acceptă Keep-Alive (există), atunci valoarea Connection din răspuns este întotdeauna apropiată.
Prin urmare, în opinia mea, tactica corectă de browser este următoarea:
1. emite Conexiune: Keep-Alive în cerere;
2. Starea conexiunii poate fi evaluată după câmpul Conexiune din răspuns.
Tipul de conținut(„tipul de conținut”) - conține o desemnare a tipului de conținut al răspunsului.
În funcție de valoarea Content-Type, browserul interpretează răspunsul ca o pagină HTML, imagine gif sau jpeg, ca fișier pentru a fi salvat pe disc, sau orice altceva, și ia măsurile corespunzătoare. Valoarea Content-Type pentru browser este aceeași cu valoarea extensiei de fișier pentru Windows.
Unele tipuri de conținut:
text/html - text în format HTML (pagina web);
text/plain - text simplu (similar cu Notepad);
imagine/jpeg - imagine în format JPEG;
imagine/gif - la fel, în format GIF;
application/octet-stream - un flux de „octeți” (adică doar octeți) pentru a scrie pe disc.
De fapt, există mai multe tipuri de conținut.
Conținut-Lungime(„lungimea conținutului”) - lungimea conținutului răspunsului în octeți.
Modificat ultima dată("Modificat ultima dată") - data ultima schimbare document.
Vă prezentăm o descriere a principalelor aspecte ale protocolului HTTP - un protocol de rețea care, de la începutul anilor 90 până în prezent, permite browserului dvs. să încarce pagini web. Acest articol a fost scris pentru cei care abia încep să lucreze cu rețele de calculatoare și să dezvolte aplicații de rețea și care încă le este greu să citească singuri specificațiile oficiale.
HTTP- un protocol de transfer de date utilizat pe scară largă, destinat inițial transferului de documente hipertext (adică documente care pot conține link-uri care permit navigarea către alte documente).
Abrevierea HTTP reprezintă Protocolul de transfer hipertext, „protocol de transfer hipertext”. Conform specificației OSI, HTTP este un protocol de aplicație (superior, al 7-lea). Versiunea actuală a protocolului, HTTP 1.1, este descrisă în specificația RFC 2616.
Protocolul HTTP implică utilizarea unei structuri de transfer de date client-server. Aplicația client generează o cerere și o trimite către server, după care software-ul server procesează cererea, generează un răspuns și îl trimite înapoi clientului. Aplicația client poate continua apoi să trimită alte solicitări, care vor fi procesate în același mod.
O sarcină care este rezolvată în mod tradițional folosind protocolul HTTP este schimbul de date între o aplicație de utilizator care accesează resurse web (de obicei un browser web) și un server web. În prezent, datorită protocolului HTTP operează World Wide Web.
HTTP este adesea folosit ca protocol de transport pentru alte protocoale de nivel de aplicație, cum ar fi SOAP, XML-RPC și WebDAV. În acest caz, se spune că protocolul HTTP este folosit ca „transport”.
API-ul multor produse software implică și utilizarea HTTP pentru transferul de date - datele în sine pot fi în orice format, de exemplu, XML sau JSON.
De obicei, transferul de date HTTP se realizează prin conexiuni TCP/IP. În acest caz, software-ul server utilizează de obicei portul TCP 80 (și, dacă portul nu este specificat în mod explicit, atunci software-ul client utilizează de obicei portul 80 în mod implicit pentru deschiderea conexiunilor HTTP), deși poate folosi oricare altul.
Cum se trimite o solicitare HTTP?
Cel mai simplu mod de a înțelege protocolul HTTP este să încercați să accesați manual o resursă web. Imaginează-ți că ești browser și ai un utilizator care își dorește foarte mult să citească articole de Anatoly Alizar.Să presupunem că a introdus următoarele în bara de adrese:
Http://alizar.site/
În consecință, tu, ca browser web, acum trebuie să te conectezi la serverul web de la alizar.site.
Pentru a face acest lucru, puteți utiliza orice utilitar adecvat de linie de comandă. De exemplu, telnet:
Telnet alizar.site 80
Permiteți-mi să clarific imediat că, dacă vă răzgândiți brusc, apăsați Ctrl + „]” și apoi introduceți - acest lucru vă va permite să închideți conexiunea HTTP. Pe lângă telnet, puteți încerca nc (sau ncat) - în funcție de gusturi.
După ce vă conectați la server, trebuie să trimiteți o solicitare HTTP. Acest lucru, apropo, este foarte ușor - cererile HTTP pot consta doar din două linii.
Pentru a genera o cerere HTTP, trebuie să compuneți o linie de pornire și, de asemenea, să setați cel puțin un antet - acesta este antetul Host, care este obligatoriu și trebuie să fie prezent în fiecare solicitare. Faptul este că conversia unui nume de domeniu la o adresă IP se realizează pe partea clientului și, în consecință, atunci când deschideți o conexiune TCP, serverul la distanță nu are nicio informație despre adresa care a fost folosită pentru conexiune: ar putea fi, de exemplu, adresa alizar..ru sau m.. Cu toate acestea, de fapt, conexiunea la rețea se deschide în toate cazurile cu nodul 212.24.43.44 și chiar dacă inițial la deschiderea conexiunii nu această adresă IP a fost specificat, dar un nume de domeniu, atunci serverul raportează că acest lucru nu este informat în niciun fel - și de aceea această adresă trebuie trecută în antetul Gazdă.
Linia de cerere de pornire (inițială) pentru HTTP 1.1 este compusă conform următoarei scheme:
De exemplu (o astfel de linie de pornire poate indica faptul că pagina principală a site-ului este solicitată):
Și, desigur, nu uitați că orice tehnologie devine mult mai simplă și mai clară atunci când începeți să o utilizați.
Mult succes si invatare fructuoasa!
Etichete:
- http
- alizar
- spdy
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 revoltător și acum vom dezvălui această rușine. Deci, ce este protocolul HTTP și pentru ce este folosit?
1.1 Client și server
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. Cel mai simplu HTTP Solicitarea ar putea arăta, de exemplu, 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 (ne vom analiza mai jos pe unele dintre ele).
* http://www.php.net/ - URI (adresa) de la care dorim sa primim macar cateva informatii (firesc, speram sa invatam pagina HTML).
* HTTP/1.0 - tipul și versiunea protocolului pe care îl vom folosi atunci când comunicăm 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 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 rnrn. Ca răspuns, veți primi cod HTML pagina principala site-ul www.php.net.
1.3 Structura cererii
Să vedem în ce constă o solicitare HTTP. Totul este destul de simplu. Să începem cu faptul că o solicitare HTTP este un text complet semnificativ. În ce constă? caz general? Vom lua î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 prin care va fi procesată resursa Request-URI poate fi GET, POST, PUT, DELETE sau HEAD.
* Request-URI - relativ sau referință absolută la 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 - versiune Protocolul HTTP, în cazul nostru „HTTP/1.0”.
Suntem extrem de interesați de metodele de procesare GET și POST. Cu metoda GET puteți trece 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 antetului.
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.
* Request-Header - parte a antetului care descrie cererea.
Request-Header poate avea următorii parametri : Permite, Autorizare, De la, Dacă-Modificat-De când, Referer, User-Agent.
În acest capitol, nu vom acoperi parametrul Autorizare, deoarece este folosit pentru a accesa resurse închise, ceea ce nu este necesar foarte des. Puteți afla cum să creați singur un antet de acces autorizat la www.w3c.org.
* Permite - setează metode de procesare acceptabile.
Format: „Permite: GET | HEADn”.
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.
* De la - Adresa de e-mail care a trimis cererea.
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 specificată în GMT în același format ca și pentru parametrul Data din Antetul General.
* Referrer - un link absolut către pagina de pe care a fost inițiată solicitarea, adică un link către pagina de pe care utilizatorul a venit 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.
Această parte a cererii specifică parametrii 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 Entity-Body.
Format: „Codificarea conținutului: x-gzip | x-compress | alt tip”.
Exemplu: „Codificarea conținutului: x-gzipn”. Caracterul „|”. înseamnă cuvântul „sau”, adică asta sau aia sau aia etc.
Un alt tip poate indica modul în care sunt codificate datele, de ex. metoda POST: „Codificarea conținutului: 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 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: 26457n”.
* Content-Type - tipul datelor transmise.
De exemplu: „Content-Type: text/htmln”.
* Expiră - Ora la care pagina ar trebui să fie ștearsă din memoria cache a browserului.
Format: „Expiră: datat”. Formatul de dată este același cu formatul de dată pentru parametrul Date din General-Header.
* Last-Modified - ora ultimei modificări a datelor trimise.
Format: „Ultima modificare: datată”. Formatul de dată este același cu formatul de dată pentru parametrul Date din General-Header.
* Extention-header - 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 „ParameterName: parametervaluen”. Acești parametri vor fi ignorați dacă programul client nu știe cum să-i proceseze.
De exemplu: „Cookie: r=1rn” – setează cookie-uri 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? 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ă.
OBȚINE http:
Gazdă: www. site-ul. fugi
Cookie: venit = 1rn
rn
Aceasta cerere 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ă acest lucru această pagină se află pe serverul www.site.ru, câmpul Referer indică faptul 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 e 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.
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
Login-ul nostru este „Petya Vasechkin” De ce ar trebui să scriem Petya%20Vasechkin? Asta pentru ca Simboluri speciale pot fi recunoscute de server ca semne ale prezenței unui nou parametru sau 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 completa a acestui algoritm poate fi găsit aici, iar PHP are funcții rawurlencode și rawurldecode pentru codificare ș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 exact acest tip solicitările este utilizat 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 algoritmul application/x-www-form-urlencoded și multipart/form-data. Diferențele dintre acești algoritmi sunt destul de semnificative. Cert este că primul tip de algoritm a fost creat cu mult timp în urmă, când limbaj HTML nu au oferit încă posibilitatea de a transfera fișiere prin Formulare HTML. Deci, să ne uităm la acești algoritmi cu exemple.
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:
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 indică 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 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:
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ă fișiere prin formulare, consorțiul W3C s-a apucat să perfecționeze formatul Solicitare POST A. Până atunci, formatul MIME (Multipurpose Internet Mail Extensions - extensii de protocol multifuncțional pentru crearea Mesaje de e-mail), prin urmare, pentru a nu reinventa roata, am decis să folosim piesa a acestui format generarea de mesaje pentru a crea cereri 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. Puteți transfera date într-o singură solicitare tipuri variate(cum in Scrisoare poștală Puteți transfera fișiere simultan cu text).
Asadar, haideti sa începem. Să luăm din nou același exemplu cu transferul de autentificare și parolă, 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 evidențiat în mod deliberat câteva caractere rn 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. Limita poate fi un șir format din litere latineși numere, precum și alte simboluri (din păcate, nu-mi amintesc care dintre ele). În corpul cererii, „--” se adaugă 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 și valoarea acesteia este dimensiunea întregului Entity-Body, care apare după al doilea rn următorul conținut-lungime: 209rn. Acestea. 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.
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
Tip de conținut: date multiple/form-date; limita = 1BEF0A57BE110FD467Arn
Conținut - Lungime: 491rn
rn
-- 1BEF0A57BE110FD467Arn
Conţinut - Dispoziţie : formă - date ; nume = "news_header" rn
rn
Stiri de exemplu
-- 1BEF0A57BE110FD467Arn
Conţinut - Dispoziţie : formă - date ; nume = "fișier_știri" ; filename = "news.txt" rn
Conținut - Tip: aplicație / octet - streamrn
Conținut - Transfer - Codificare : binaryrn
rn
Iată știrile,
care se află în dosarul de știri. txtrn
-- 1BEF0A57BE110FD467A -- rn
ÎN în acest exemplu prima secțiune trimite titlul știrii, iar a doua secțiune trimite fișierul news.txt. Dacă sunteți atent, veți vedea câmpurile pentru numele fișierului și tipul conținutului în a doua secțiune. Câmpul nume de fișier specifică numele fișierului trimis, iar câmpul Content-Type specifică tipul acestui fișier. 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. Majoritate Scripturi CGI scris oameni destepti, așa că le place să verifice tipul fișierului primit, care este î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, îl ignoră acest fișier. Prin urmare, atunci când creaț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 folosit extrem de rar, formatul este prea încăpător)
În exemplul nostru, este generată o cerere în care fisier 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 :-). Citiți cu atenție secțiunea despre funcțiile pentru lucrul cu prize sau despre funcțiile modulului CURL în documentație oficială RNR.
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.
| Înapoi |
O solicitare HTTP sau un mesaj constă din trei părți: linia de interogare și corpul 
