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 si dezvolta 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ă hipertext Protocolul de transfer , „protocol de transfer hipertext”. Conform specificației OSI, HTTP este un protocol de aplicație (superior, al 7-lea). Curent activat în 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 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 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-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 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?

Să presupunem că a intrat bara de adrese urmatoarele:

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 comandă. 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 solicitare HTTP, trebuie să compuneți o linie de pornire și, de asemenea, să setați cel puţin un antet este antetul Gazdă, 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 distanță 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 la rețea 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 nume de domeniu, 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ă solicitați pagina de start site):

Ș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ă pentru World Wide Web.

Protocolul HTTP funcționează după cum urmează: programul client stabilește o conexiune TCP cu serverul ( camera 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ă 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, el a fost 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.

PUNE- plasați documentul pe server. Din cate stiu 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.

Liniile de după linia principală de interogare au următorul 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.

User-Agent- valoarea este „codul” browserului, de exemplu:

Mozilla/4.0 (compatibil; MSIE 5.0; Windows 95; DigExt)

Accepta- o listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru un anumit browser, de exemplu pentru IE5:

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 în regulă” (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.

Tip 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ă mult mai multe tipuri de conținut.

Conținut-Lungime(„lungimea conținutului”) - lungimea conținutului răspunsului în octeți.

Ultima modificare("Modificat ultima dată") - data ultima schimbare document.

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 în regulă” (OK).

Descrierea verbală a erorii- „descifrarea” codului anterior. De exemplu, pentru 200 este OK, pentru 500 este Internal Server Error.

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.

Tip 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, o imagine gif sau jpeg, un fișier care urmează să fie salvat pe disc sau 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ă mult mai multe tipuri de conținut.

Conținut-Lungime(„lungimea conținutului”) - lungimea conținutului răspunsului în octeți.

Ultima modificare(„Ultima modificare”) - data la care documentul a fost modificat ultima dată.

Protocolul de transfer hipertext (HTTP) este un protocol de nivel înalt (și anume, la nivel de aplicație) care oferă viteza necesară transmiterea de date necesară pentru sistemele de informare hipermedia distribuite. HTTP este folosit de proiect La nivel mondial Web din 1990.

Practic sisteme informatice necesită mai mult decât căutarea, modificarea și adnotarea datelor primitive. HTTP/1.0 oferă set deschis metode care pot fi folosite pentru precizarea scopurilor cererii. Ele sunt construite pe o disciplină de referință, în care un Universal Resource Identifier (URI), sub forma unei locații (URL) sau nume (URN), este utilizat pentru a indica resursa căreia trebuie aplicată o anumită metodă. Formatul mesajului este similar cu Internet Mail sau Multipurpose Internet Mail Extensions (MIME).

HTTP/1.0 este, de asemenea, utilizat pentru comunicațiile între diverse browsere și gateway-uri de utilizator care oferă acces hipermedia la protocoalele de Internet existente, cum ar fi SMTP, NNTP, FTP, Gopher și WAIS. HTTP/1.0 este conceput pentru a permite unor astfel de gateway-uri servere proxy, fără nicio pierdere, transmite date utilizând protocoalele menționate ale versiunilor anterioare.

Structura generală

HTTP se bazează pe o paradigmă cerere/răspuns. Programul solicitant (numit de obicei client) stabilește o conexiune cu programul de serviciu de recepție (numit de obicei server) și trimite o cerere către server sub următoarea formă: metoda de solicitare, URI, versiunea protocolului, urmată de un mesaj de tip MIME care conțin informații de control al cererii, informații despre client și poate corpul mesajului. Serverul răspunde cu un mesaj care conține un șir de stare (inclusiv versiunea protocolului și un cod de stare de succes sau eroare), urmat de un mesaj asemănător MIME care include informații despre server, metainformații despre conținutul răspunsului și poate răspunsul. corpul însuși. Trebuie remarcat faptul că un program poate fi atât client, cât și server în același timp. Utilizarea acestor termeni în acest text se referă numai la rolul îndeplinit de program în timpul acelei sesiuni de comunicare, și nu la funcții generale programe.

Pe Internet, comunicațiile se bazează de obicei pe protocoale TCP/IP. Pentru WWW, numărul de port implicit este TCP 80, dar pot fi utilizate și alte numere de port - acest lucru nu exclude posibilitatea de a utiliza HTTP ca protocol de nivel superior.

Pentru majoritatea aplicațiilor, o sesiune este deschisă de client pentru fiecare cerere și închisă de server odată ce răspunsul la cerere a fost finalizat. Cu toate acestea, aceasta nu este o caracteristică a protocolului. Atât clientul, cât și serverul trebuie să poată închide sesiunea de comunicare, de exemplu, ca urmare a unei acțiuni a utilizatorului. În orice caz, o deconectare inițiată de oricare dintre părți încheie cererea curentă, indiferent de starea acesteia.

Concepte generale

O cerere este un mesaj trimis de un client către un server.
Prima linie a acestui mesaj include metoda care trebuie aplicată resursei solicitate, identificatorul resursei și versiunea protocolului de utilizat. Pentru compatibilitate cu protocolul HTTP/0.9, există două formate de solicitare HTTP:

Interogare = Interogare simplă | Solicitare completă Solicitare simplă = „OBȚINE” SP Solicitat-URI CRLF Solicitare completă = Stare linie *(Antet general | Antet cerere | Antet conținut) CRLF [ Conținut-Solicitare]

Dacă un server HTTP/1.0 primește o solicitare simplă, acesta trebuie să răspundă cu un răspuns simplu HTTP/0.9. Un client HTTP/1.0 capabil să proceseze un răspuns complet nu ar trebui să trimită niciodată o cerere simplă.

Stare linie

Linia de stare începe cu o linie cu numele metodei, urmată de URI-ul de solicitare și versiunea protocolului utilizată. Linia de stare se termină cu caractere CRLF. Elementele de linie sunt separate prin spații (SP). Caracterele LF și CR nu sunt permise în linia de stare, cu excepția secvenței de închidere CRLF.

String-Status = Metoda SP Solicitare URI SP Versiune-HTTP CRLF

Trebuie remarcat faptul că diferența dintre linia de stare a cererii complete și linia de stare Cerere simplă constă în prezența câmpului HTTP-Version.

Metodă

Câmpul Method specifică metoda care trebuie aplicată resursei identificate de Request URI. Numele metodelor sunt sensibile la majuscule. Lista existentă metodele pot fi extinse.

Metoda = "GET" | „Cap” | „PUNEȚI” | „POST” | „ȘTERGERE” | „LINK” | „UNLINK” | metoda suplimentara

Lista metodelor permise de o anumită resursă poate fi specificată în câmpul Titlu-Conținut din „Puncte”. Cu toate acestea, clientul este întotdeauna notificat de către server printr-un cod de stare de răspuns dacă aplicația este permisă această metodă pentru resursa specificată, de la admisibilitatea utilizării diverse metode se poate schimba dinamic. Dacă o anumită metodă este cunoscută de server, dar nu este permisă pentru resursa specificată, serverul TREBUIE să returneze un cod de stare „405 Method Not Allowed” și un cod de stare „501 Not Implemented” dacă metoda nu este cunoscută. sau nu este acceptat de serverul dat. Metodele comune HTTP/1.0 sunt descrise mai jos.

OBŢINE

Metoda GET este utilizată pentru a prelua orice informație identificată de URI-ul de solicitare. Dacă URI-ul de solicitare se referă la un proces care produce date, răspunsul va fi datele generate de acel proces, nu codul de proces în sine (cu excepția cazului în care este rezultatul procesului).

Metoda GET este schimbată în „GET condiționat” dacă mesajul de solicitare include un câmp de antet „Dacă-Modified-Deci”. Ca răspuns la un GET condiționat, corpul resursei solicitate este transmis numai dacă a fost modificat de la data specificată în antetul „If-Modified-Since”. Algoritmul pentru determinarea acestui lucru include următoarele cazuri:

• Dacă codul de stare a răspunsului la cerere este altul decât „200 OK”, sau data specificată în câmpul antet „Dacă-Modified-Since” este incorectă, răspunsul va fi identic cu răspunsul normal cerere GET.
• Dacă resursa s-a schimbat de la data specificată, răspunsul va fi, de asemenea, identic cu răspunsul la o solicitare GET obișnuită.
• Dacă resursa nu a fost modificată de la data specificată, serverul va returna un cod de stare „304 Not Modified”.

Utilizarea metodei GET condiționată are ca scop descărcarea rețelei, deoarece vă permite să evitați transmiterea de informații redundante prin rețea.

CAP

Metoda HEAD este similară cu metoda GET, cu excepția faptului că serverul nu returnează un Corp de răspuns în răspuns. Metainformațiile conținute în anteturile HTTP ale unui răspuns la o solicitare HEAD trebuie să fie identice cu informațiile conținute în anteturile HTTP ale unui răspuns la o solicitare GET. Această metodă poate fi folosită pentru a obține metainformații despre o resursă fără a transmite resursa în sine prin rețea. Metoda „HEAD condiționat”, similară cu GET condiționat, este nedefinită.

POST

Metoda POST este utilizată pentru a solicita serverului să accepte informațiile incluse în cerere ca fiind subordonate resursei specificate în linia de stare din câmpul URI de solicitare. Metoda POST a fost concepută pentru a permite unul metoda generala pentru urmatoarele functii:

• Rezumat al resurselor existente
• Adăugarea de mesaje la grupuri de știri, liste poștale sau grupuri similare de articole
• Livrarea blocurilor de date către procesele de prelucrare a datelor
• Extinderea bazelor de date printr-o operație de adăugare

Funcția reală realizată de metoda POST este determinată de server și depinde de obicei de URI-ul de solicitare. Informațiile adăugate sunt tratate ca o subordonare a URI-ului specificat în același sens în care un fișier este subordonat directorului în care se află, un articol nou este subordonat grupului de știri la care este adăugat, o intrare este subordonată baza de date.

Clientul poate propune un URI pentru a identifica noua resursă prin includerea unui antet „URI” în cerere. Cu toate acestea, serverul ar trebui să trateze acest URI doar ca un indiciu și poate stoca corpul cererii sub un URI diferit sau fără URI deloc.

Dacă ca urmare a prelucrării Solicitare POST a fost creat noua resursa, răspunsul trebuie să aibă un cod de stare „201 Created” și să conțină URI-ul noii resurse.

PUNE

Metoda PUT solicită serverului să stocheze Corpul de solicitare sub un URI egal cu URI de solicitare. Dacă URI-ul de solicitare se referă la o resursă deja existentă, organismul de solicitare ar trebui tratat ca o versiune modificată a acelei resurse. Dacă resursa la care face referire URI-ul de solicitare nu există, iar URI-ul dat poate fi considerat o descriere pentru o nouă resursă, serverul poate crea o resursă cu URI-ul dat. Dacă a fost creată o nouă resursă, serverul trebuie să informeze clientul solicitant printr-un răspuns cu codul de stare „201 Created”. Dacă o resursă existentă a fost modificată, trebuie trimis un răspuns „200 OK” pentru a informa clientul că operația a avut succes. Dacă o resursă cu URI specificat nu poate fi creată sau modificată, trebuie trimis un mesaj de eroare corespunzător.

Diferența fundamentală dintre metodele POST și PUT este sens diferit Solicitați câmpuri URI. Pentru metoda POST acest URI specifică o resursă care va manipula informațiile conținute în corpul cererii ca anexă. Resursa poate fi un proces de prelucrare a datelor, o poartă către un alt protocol sau o resursă separată care permite adnotări. În schimb, URI-ul pentru o cerere PUT identifică informațiile conținute în Request-Content. Utilizatorul cererii PUT știe exact ce URI intenționează să folosească, iar destinatarul cererii nu ar trebui să încerce să aplice cererea unei alte resurse.

ŞTERGE

Metoda DELETE este folosită pentru a șterge resursele identificate printr-un URI de solicitare. Rezultatele acestei metode pe server pot fi modificate prin intervenție umană (sau prin alte mijloace). În principiu, clientul nu poate fi niciodată sigur că operația de ștergere a fost finalizată, chiar dacă codul de stare trimis de server indică faptul că acțiunea a avut succes. Cu toate acestea, serverul nu ar trebui să raporteze succes până când este pe cale să se ștergă în momentul răspunsului această resursă sau mutați-l într-o zonă inaccesibilă.

LEGĂTURĂ

Metoda LINK stabilește relații între resursa existentă specificată în Request URI și alte resurse existente. Diferenţă metoda LINK din alte metode care permit stabilirea de legături între documente este că metoda LINK nu permite trecerea Organismului de Solicitare într-o cerere și că în urma acestei metode nu se creează noi resurse.

DECONECTARE

Metoda UNLINK elimină una sau mai multe relații de legătură pentru resursa specificată în URI de solicitare. Aceste relații pot fi stabilite folosind metoda LINK sau o altă metodă care acceptă antetul „Link”. Eliminarea unui link către o resursă nu înseamnă că resursa încetează să existe sau devine indisponibilă pentru referințe viitoare.

Câmpuri pentru antetul cererii

Câmpurile Request-Header permit clientului să trimită către server Informații suplimentare despre cerere și despre clientul însuși.

Request-Header = Accept | Accept-Charset | Acceptare-Codificare |

Acceptare-Limba | Autorizare | Din |

Dacă-Modificat-Deoarece |

Pragma | Referitor | User-Agent | antetul extensiei

În plus, anteturi suplimentare pot fi definite prin mecanismul de extensie; aplicațiile care nu le recunosc trebuie să trateze aceste anteturi ca Header-Content. Unele dintre câmpurile antetului cererii vor fi discutate mai jos. Din Dacă câmpul De la este prezent, acesta trebuie să conțină e-mail complet

adresa utilizatorului care controlează programul agent care face cereri. Această adresă trebuie specificată în formatul definit în RFC 822. Format a acestui domeniu

următorul: De la = „De la” „:” specificarea adresei. De exemplu: Din:[email protected] Acest câmp poate fi folosit pentru funcțiile de conectare, precum și pentru a identifica sursa solicitărilor incorecte sau nedorite. Nu ar trebui folosit ca o formă neclasificată de control al accesului. Interpretarea acestui câmp este că cererea în curs de procesare este făcută în numele utilizator dat , care își asumă responsabilitatea pentru metoda folosită. În special, agenții roboți ar trebui să utilizeze acest antet, astfel încât persoana responsabilă pentru robot să poată fi contactată dacă apar probleme. Adresa de e-mail de Internet indicată în acest câmp nu trebuie să se potrivească cu adresa gazdei de la care a fost trimisă această solicitare. Dacă este posibil, adresa ar trebui să fie accesibilă adresa de internet

indiferent dacă este de fapt Internet

Dacă-Modificat-De vreme ce

Câmpul antet If-Modified-Since este folosit cu metoda GET pentru a-l face condiționat: dacă resursa solicitată nu s-a schimbat în timpul specificat în acest câmp, o copie a acelei resurse nu va fi returnată de server; în schimb, va fi returnat un răspuns „304 Not Modified” fără un corp de răspuns.

If-Modified-Since = „If-Modified-Since” „:” Data HTTP

Exemplu de utilizare a unui antet:

Scopul acestei caracteristici este de a permite actualizarea eficientă a informațiilor cache-urile locale cu un minim informatiile transmise. Același rezultat poate fi obținut prin utilizarea metodei HEAD urmată de un GET dacă serverul a indicat că conținutul documentului s-a modificat.

User-Agent

Câmpul antet User-Agent conține informații despre agentul utilizator care a trimis cererea. Acest câmp este utilizat pentru statistici, urmărirea erorilor de protocol și recunoaștere automată agenţi utilizatori. Deși nu este obligatoriu, agenții utilizatori ar trebui să includă întotdeauna acest câmp în solicitările lor. Câmpul poate conține mai multe rânduri reprezentând numele produsului software, o bară oblică opțională care indică versiunea produsului și alte produse software, care formează o parte importantă a agentului utilizator. Prin convenție, produsele sunt enumerate în ordinea descrescătoare a importanței lor pentru identificarea aplicației.

User-Agent = "User-Agent" ":" 1*(produs) produs = șir ["/" versiune-produs] versiune-produs = șir

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Rândul care descrie numele produsului ar trebui să fie scurt și la obiect - utilizarea acestui titlu pentru a face publicitate oricărei alte informații irelevante nu este permisă și va fi considerată incompatibilă cu protocolul. Deși orice șir poate fi prezent în câmpul versiunea produsului, linie dată ar trebui folosit doar pentru a indica versiunea produsului. Câmpul User-Agent poate include informații suplimentare în comentarii care nu fac parte din valoarea sa.

Structura răspunsului

După primirea și interpretarea cererii, serverul trimite un răspuns în conformitate cu următorul formular:

Răspuns = Simplu-Răspuns | Răspuns complet Răspuns simplu = [ Conținut-Răspuns ] Răspuns complet = Stare-linie *(Common-Header | Response-Header | Content-Header) CRLF [ Response-Content ]

Un răspuns simplu ar trebui trimis doar ca răspuns la o solicitare simplă HTTP/0.9 sau dacă serverul acceptă doar protocolul limitat HTTP/0.9. Dacă un client trimite o cerere completă HTTP/1.0 și primește un răspuns care nu începe cu o linie de stare, trebuie să presupună că răspunsul serverului este un răspuns simplu și să-l proceseze în consecință. Trebuie remarcat faptul că Simple-Response constă doar din informațiile solicitate (fără anteturi) și fluxul de date se oprește în momentul în care serverul închide sesiunea de comunicare.

Stare linie

Prima linie a cererii complete este o linie de stare constând din versiunea protocolului urmată de cod digital status și propoziția text asociată. Toate elementele Line-Status sunt separate prin spații. Caracterele CR și LF nu sunt permise, cu excepția secvenței CRLF de sfârșit.

Line-Status=Versiune-HTTP SP Stare-Cod SP Fraza-Explicație.

Deoarece linia de stare începe întotdeauna cu versiunea de protocol „HTTP/” 1*DIGIT „.” 1*DIGIT (ex. HTTP/1.0), existența acestei expresii este considerată fundamentală pentru a determina dacă răspunsul este un răspuns simplu sau un răspuns complet. Deși formatul Simplu-Răspuns nu împiedică apariția unei astfel de linii (ceea ce ar duce la interpretarea greșită a mesajului de răspuns ca un răspuns complet), probabilitatea unei astfel de apariții este aproape de zero.

Codul de stare și explicația acestuia

Elementul Status Code este un cod întreg din 3 cifre care identifică rezultatul unei încercări de interpretare și satisfacere a cererii. Expresia explicativă care urmează este destinată pe scurt descriere text Cod de stare. Codul de stare este destinat să fie utilizat de o mașină, în timp ce expresia explicativă este destinată unei persoane. Clientul nu este obligat să examineze și să afișeze Expresia explicativă.

Prima cifră a codului de stare este destinată să determine clasa răspunsului. Ultimele două cifre nu joacă niciun rol de clasificare. Există 5 semnificații pentru prima cifră:

1. 1xx: Informațional - Nu este folosit, dar rezervat pentru utilizare ulterioară
2. 2xx: Succes - Solicitarea a fost pe deplin primită, înțeleasă și acceptată pentru procesare.
3. 3xx: Redirecționare - clientul ar trebui să ia acțiuni ulterioare pentru a finaliza cererea cu succes. Acțiunea suplimentară necesară poate fi uneori efectuată de client fără interacțiunea utilizatorului, dar se recomandă insistent ca aceasta să apară numai în cazurile în care metoda utilizată în cerere este indiferentă (GET sau HEAD).
4. 4xx: Eroare client - O solicitare care conține sintaxă invalidă nu poate fi finalizată cu succes. Clasa 4xx este destinată să descrie cazurile în care a fost făcută o eroare din partea clientului. Dacă clientul nu a finalizat încă cererea când primește un răspuns cu Status Code - 4xx, trebuie să înceteze imediat transmiterea datelor către server. Acest tip Codurile de stare sunt aplicabile pentru orice metodă utilizată în cerere.
5. 5xx: Eroare server - Serverul nu a putut oferi un răspuns la o solicitare trimisă corect. În aceste cazuri
   serverul fie știe că a făcut o eroare, fie nu poate procesa cererea. Cu excepția răspunsurilor la solicitările HEAD, serverul trimite o descriere a situației de eroare și dacă condiția este temporară sau permanentă în Conținutul răspunsului. Acest tip de cod de stare este aplicabil pentru orice metode utilizate în cerere.

Semnificațiile individuale ale codurilor de stare și frazele explicative corespunzătoare sunt prezentate mai jos. Aceste fraze explicative sunt doar recomandate - pot fi înlocuite cu orice alte fraze care își păstrează sensul și sunt permise de protocol.

Status-Cod = "200" ; OK | „201” ; Creat | "202" ; Acceptat | "203" ; Informații provizorii | "204" ; Fără conținut | "300"; Alegeri multiple | "301"; Mutat permanent | "302"; Mutat temporar | "303"; Metoda | "304"; Nemodificat | "400"; Solicitare greșită | "401"; Neautorizat | "402"; Plată necesară | "403"; Interzis | "404"; Nu a fost găsit | "405"; Metoda nu este permisă | "406"; Niciunul acceptabil | "407"; Este necesară autentificarea proxy | "408"; Solicitare Timeout | "409"; Conflict | "410"; A plecat | "500"; Eroare internă server | "501"; Neimplementat | "502"; Gateway rău | "503"; Serviciu indisponibil | "504"; Timeout Gateway | Cod extensie Cod extensie = 3DIGIT Expresie-Explicație = șir *(șir SP)

Din aplicații HTTPÎnțelegerea tuturor codurilor de stare nu este necesară, deși o astfel de înțelegere este în mod evident de dorit. Cu toate acestea, aplicațiile trebuie să poată recunoaște clase de coduri de stare (identificate prin prima cifră) și să trateze toate codurile de stare de stare de răspuns ca și cum ar fi echivalente cu codul de stare x00.

Antet-Câmpuri de răspuns

Câmpurile de antet de răspuns permit serverului să transmită informații suplimentare despre răspuns care nu pot fi incluse în linia de stare. Aceste câmpuri de antet nu sunt destinate să transmită informații despre conținutul răspunsului trimis ca răspuns la cerere, dar pot conține informații despre serverul însuși.

Response-Header= Public | Reîncercați-După | Server | WWW-Autentificare | antetul extensiei

Deşi câmpuri suplimentare anteturile de răspuns pot fi implementate printr-un mecanism de extensie, aplicațiile care nu recunosc aceste câmpuri trebuie să le trateze ca câmpuri Header-Content. Descriere completă Aceste câmpuri pot fi obținute din specificația protocolului HTTP CERN.

Concepte generale

Solicitarea completă și Răspunsul complet pot fi folosite pentru a transmite unele informații în cereri și răspunsuri separate. Aceste informații sunt Solicitare-Conținut sau, respectiv, Răspuns-Conținut, și Conținut-Header.

Câmpuri Titlu-Conținut

Câmpurile Header-Content conțin metainformații opționale despre Request-Content sau, respectiv, Response-Content. Dacă corpul mesajului corespunzător (cerere sau răspuns) nu este prezent, atunci Content-Header conține informații despre resursa solicitată.

Unele dintre câmpurile de antet de conținut sunt descrise mai jos.

Permite

Câmpul de antet Allow este o listă de metode pe care le suportă resursa identificată de URI-ul de solicitare. Scopul acestui câmp este de a informa cu exactitate destinatarul despre metodele valabile asociate cu resursa; acest câmp trebuie să fie prezent în răspunsul cu codul de stare „405 Metoda nepermisă”.

Allow = "Permite" ":" 1#method

Exemplu de utilizare:

Permite: GET, HEAD, PUT

Desigur, clientul poate încerca și alte metode. Cu toate acestea, este recomandat să urmați metodele indicate în acest domeniu. Acest câmp nu are o valoare implicită; dacă este lăsat nedefinit, setul de metode permise este determinat de server la momentul fiecărei solicitări.

Conținut-Lungime

Câmpul Content-Length specifică dimensiunea corpului mesajului trimis de server ca răspuns la cerere sau, în cazul unei cereri HEAD, dimensiunea corpului mesajului care ar fi trimis ca răspuns la cererea GET.

Lungimea conținutului = „Lungimea conținutului” „:” 1*CIFRĂ

De exemplu:

Lungimea conținutului: 3495

Deși nu este obligatoriu, aplicațiile sunt încurajate să utilizeze acest câmp pentru analiza dimensionării mesaj transmis, indiferent de tipul de informații pe care le conține. Pentru câmpul Content-Length, orice valoare întreagă mai mare decât zero este validă.

Tip de conținut

Câmpul de antet Content-Type identifică tipul de informații din corpul mesajului care este trimis către partea care primește sau, în cazul metodei HEAD, tipul de informații (media) care ar fi trimise dacă s-ar folosi metoda GET.

Content-Type = „Content-Type” „:” tip mediu

Tipurile media sunt definite separat.
Exemplu:

Tip de conținut: text/html; set de caractere=ISO-8859-4

Câmpul Content-Type nu are o valoare implicită.

Ultima modificare

Câmpul antet conține data și ora la care partea expeditoare crede că resursa a fost modificată ultima dată. Semantica acestui câmp este definită în termeni care descriu modul în care destinatarul ar trebui să îl interpreteze: dacă destinatarul are o copie a resursei care este mai veche decât data trecută în câmpul Ultima modificare, atunci copia trebuie considerată ca depășită. .

Last-Modified = „Ultima modificare” „:” Data HTTP

Exemplu de utilizare:

Semnificația exactă a acestui câmp de antet depinde de implementarea părții care trimite și de natura resursei în sine. Pentru fișiere, ar putea fi timpul lui ultima modificare. Pentru gateway-uri de baze de date, acesta poate fi momentul ultima actualizare date din baza de date. În orice caz, destinatarul trebuie să-și facă griji doar cu privire la rezultat - ce este în câmpul dat - și să nu se îngrijoreze de modul în care a fost obținut rezultatul.

Corpul mesajului

Corpul mesajului se referă la Conținutul Cererii sau, respectiv, Conținutul răspunsului. Corpul mesajului, dacă este prezent, este trimis în cererea sau răspunsul HTTP/1.0 în formatul și codificarea specificate de câmpurile Header-Content.

Message-Body = *OCTET (unde OCTET este orice caracter de 8 biți)

Corpul mesajului este inclus în cerere numai dacă metoda solicitării implică prezența acestuia. Pentru specificația HTTP/1.0, aceste metode sunt POST și PUT. În general, prezența unui corp de mesaj este indicată de prezența câmpurilor de antet de conținut, cum ar fi Content-Length și/sau Content-Transfer-Coding în cererea transmisă.

După ce ați citit acest articol, veți afla de ce utilizarea compresiei este atât de importantă și ce impact poate avea asupra site-ului dvs. web. Acest articol se bazează pe două cheie...

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.

HTTP

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 pornire pentru cerere și răspuns sunt format diferit- 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 (în prezent, versiunea 1.1 este actuală).

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, 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ă, nu există niciun corp de mesaj în cerere.

Exemplu de interacțiune HTTP

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

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 resurselor
• PUT - actualizare de resurse
• DELETE - ștergerea resurselor

REST intră în joc

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 acțiuni diferite. 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?

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 funcționare 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.