Protocol de transfer hipertext - Hypertext Transfer Protocol

Protocol de transfer hipertext

Standard international	RFC  1945 HTTP / 1.0 (1996) RFC  2068 HTTP / 1.1 (1997) RFC  2616 HTTP / 1.1 (1999) RFC  7230 HTTP / 1.1: Sintaxa și rutarea mesajelor (2014) RFC  7231 HTTP / 1.1: Semantică și conținut (2014) RFC  7232 HTTP / 1.1: Cereri condiționate ( 2014) RFC  7233 HTTP / 1.1: Range Requests (2014) RFC  7234 HTTP / 1.1: Caching (2014) RFC  7235 HTTP / 1.1: Autentificare (2014) RFC  7540 HTTP / 2 (2015) RFC  7541 HTTP / 2: HPACK Header Compression (2015) RFC  8164 HTTP / 2: Oportunistic Security for HTTP / 2 (2017) RFC  8336 HTTP / 2: The ORIGIN HTTP / 2 Frame (2018) RFC  8441 HTTP / 2: Bootstrapping WebSockets with HTTP / 2 (2018) RFC  8740 HTTP / 2: Utilizarea TLS 1.3 cu HTTP / 2 (2020)
Dezvoltat de	inițial CERN ; IETF , W3C
Introdus	1991 ; acum 30 de ani ( 1991 )

Hypertext Transfer Protocol ( HTTP ) este un strat de aplicație de protocol din suita Internet Protocol model pentru distribuite, colaborative, hypermedia sistemelor informatice. HTTP este fundamentul comunicării datelor pentru World Wide Web , unde documentele hipertext includ hyperlinkuri către alte resurse pe care utilizatorul le poate accesa cu ușurință, de exemplu printr-un clic de mouse sau atingând ecranul dintr-un browser web.

Dezvoltarea HTTP a fost inițiată de Tim Berners-Lee la CERN în 1989 și rezumată într-un document simplu care descrie comportamentul unui client și a unui server folosind prima versiune de protocol HTTP numită 0.9.

Dezvoltarea primelor solicitări HTTP pentru comentarii (RFC) a început câțiva ani mai târziu și a fost un efort coordonat de Internet Engineering Task Force (IETF) și World Wide Web Consortium (W3C), lucrările trecând ulterior la IETF.

HTTP / 1 a fost documentat pentru prima dată (ca versiune 1.0) în 1996. A evoluat (ca versiune 1.1) în 1997.

HTTP / 2 este o expresie mai eficientă a semanticii HTTP „pe fir” și a fost publicat în 2015 și este utilizat de 45% dintre site-urile web; acum este acceptat de practic toate browserele web și serverele web majore prin Transport Layer Security (TLS) folosind o extensie Application-Layer Protocol Negotiation (ALPN) în care este necesar TLS 1.2 sau mai nou.

HTTP / 3 este succesorul propus pentru HTTP / 2, iar două treimi din utilizatorii browserului web (atât pe desktop, cât și pe mobil) pot folosi deja HTTP / 3, pe 20% dintre site-urile care îl acceptă deja; folosește QUIC în loc de TCP pentru protocolul de transport subiacent. La fel ca HTTP / 2, nu depășește versiunile majore anterioare ale protocolului. Suportul pentru HTTP / 3 a fost adăugat mai întâi în Cloudflare și Google Chrome și este activat și în Firefox .

Prezentare tehnică

Adresă URL care începe cu schema HTTP și eticheta de nume de domeniu WWW

HTTP funcționează ca protocol cerere-răspuns în modelul de calcul client-server. Un browser web , de exemplu, poate fi clientul și o aplicație care rulează pe un computer care găzduiește un site web poate fi serverul . Clientul trimite un mesaj de solicitare HTTP către server. Serverul, care furnizează resurse precum fișiere HTML și alt conținut, sau îndeplinește alte funcții în numele clientului, returnează clientului un mesaj de răspuns . Răspunsul conține informații despre starea finalizării cererii și poate conține, de asemenea, conținutul solicitat în corpul mesajului.

Un browser web este un exemplu de agent utilizator (UA). Alte tipuri de agenți de utilizator includ software-ul de indexare utilizat de furnizorii de căutare ( crawlerele web ), browserele vocale , aplicațiile mobile și alte programe care accesează, consumă sau afișează conținut web.

HTTP este conceput pentru a permite elementelor de rețea intermediare să îmbunătățească sau să permită comunicațiile între clienți și servere. Site-urile cu trafic mare beneficiază adesea de servere cache web care livrează conținut în numele serverelor din amonte pentru a îmbunătăți timpul de răspuns. Browserele web ascund în cache resursele web accesate anterior și le reutilizează, ori de câte ori este posibil, pentru a reduce traficul de rețea. Serverele proxy HTTP la granițele rețelei private pot facilita comunicarea clienților fără o adresă globală, prin transmiterea mesajelor cu servere externe.

Pentru a permite nodurilor HTTP intermediare (servere proxy, cache-uri web etc.) să-și îndeplinească funcțiile, unele dintre anteturile HTTP (găsite în solicitări / răspunsuri HTTP) sunt gestionate hop-by-hop, în timp ce alte antete HTTP sunt gestionate de la un capăt la altul end (gestionat numai de clientul sursă și de serverul web țintă).

HTTP este un protocol de strat de aplicație proiectat în cadrul suitei de protocol Internet . Definiția sa presupune un protocol de strat de transport subiacent și fiabil , astfel Protocolul de control al transmisiei (TCP) este utilizat în mod obișnuit. Cu toate acestea, HTTP poate fi adaptat pentru a utiliza protocoale nesigure, precum User Datagram Protocol (UDP), de exemplu în HTTPU și Simple Service Discovery Protocol (SSDP).

Resursele HTTP sunt identificate și localizate în rețea de către Uniform Resource Locators (URL-uri), utilizând schemele Uniform Resource Identifiers (URI) http și https . Așa cum este definit în RFC  3986 , URI-urile sunt codificate ca hyperlinkuri în documente HTML , astfel încât să formeze documente hipertext interconectate .

HTTP / 1.1 este o revizuire a HTTP-ului original (HTTP / 1.0). În HTTP / 1.0 se face o conexiune separată la același server pentru fiecare solicitare de resursă. În schimb, HTTP / 1.1 poate reutiliza o conexiune pentru a face mai multe solicitări de resurse (adică pagini HTML, cadre, imagini, scripturi , foi de stil etc.).

Comunicațiile HTTP / 1.1 au, prin urmare, o latență mai mică, deoarece stabilirea conexiunilor TCP prezintă o suprasolicitare considerabilă, în special în condiții de trafic ridicat.

HTTP / 2 este o revizuire a HTTP / 1.1 anterioară pentru a menține același model client-server și aceleași metode de protocol, dar cu aceste diferențe în ordine:

• să utilizați o reprezentare binară comprimată a metadatelor (anteturi HTTP) în loc de una textuală, astfel încât antetele să necesite mult mai puțin spațiu;
• să utilizați o singură conexiune TCP / IP (de obicei criptată ) per domeniu de server accesat în loc de 2..8 conexiuni TCP / IP;
• să utilizați unul sau mai multe fluxuri bidirecționale pe conexiune TCP / IP în care solicitările și răspunsurile HTTP sunt defalcate și transmise în pachete mici pentru a rezolva problema HOLB ( blocarea capului de linie ; NOTĂ: în practică aceste fluxuri sunt utilizate ca TCP multiple / Sub-conexiuni IP la cereri / răspunsuri simultane multiplex , reducând astfel numărul de conexiuni TCP / IP reale de pe partea serverului, de la 2..8 per client la 1 și permițând mai multor clienți să fie deserviți simultan);
• pentru a adăuga o capacitate push pentru a permite aplicației server să trimită date către clienți ori de câte ori sunt disponibile date noi (fără a forța clienții să solicite periodic date noi către server utilizând metode de interogare ).

Prin urmare, comunicațiile HTTP / 2 au o latență mult mai redusă și, în majoritatea cazurilor, chiar mai multă viteză decât comunicațiile HTTP / 1.1.

HTTP / 3 este o revizuire a HTTP / 2 anterioare pentru a utiliza protocoalele de transport UDP + QUIC în locul conexiunilor TCP / IP și astfel pentru a depăși problema congestiei conexiunii TCP / IP care poate bloca sau încetini fluxul de date al tuturor pâraie.

Istorie

Tim Berners-Lee

Termenul de hipertext a fost inventat de Ted Nelson în 1965 în Proiectul Xanadu , care a fost la rândul său inspirat de viziunea lui Vannevar Bush din anii 1930 asupra sistemului „ memex ” de recuperare și gestionare a informațiilor bazate pe microfilme descris în eseul său din 1945 „ As We May Think ". Tim Berners-Lee și echipa sa de la CERN sunt creditați cu inventarea HTTP originală, împreună cu HTML și tehnologia asociată pentru un server web și un browser web bazat pe text. Berners-Lee a propus pentru prima dată proiectul „WorldWideWeb” în 1989 - acum cunoscut sub numele de World Wide Web . Primul server web a intrat în funcțiune în 1990. Protocolul utilizat avea o singură metodă, și anume GET, care ar solicita o pagină de la un server. Răspunsul de la server a fost întotdeauna o pagină HTML.

Prima versiune documentată a HTTP a fost scrisă în 1991. Dave Raggett a condus Grupul de lucru HTTP (HTTP WG) în 1995 și a dorit să extindă protocolul cu operațiuni extinse, negociere extinsă, metainformații mai bogate, legate de un protocol de securitate care a devenit mai mult eficient prin adăugarea de metode suplimentare și câmpuri de antet . RFC  1945 a introdus oficial și a recunoscut versiunea HTTP 1.0 în 1996.

HTTP WG a planificat să publice noi standarde în decembrie 1995, iar suportul pentru pre-standard HTTP / 1.1 bazat pe RFC  2068 în curs de dezvoltare (numit HTTP-NG) a fost adoptat rapid de principalii dezvoltatori de browsere la începutul anului 1996. Adopția utilizatorului final dintre noile browsere a fost rapidă. În martie 1996, o companie de găzduire web a raportat că peste 40% din browserele utilizate pe Internet respectă HTTP 1.1. Aceeași companie de găzduire web a raportat că până în iunie 1996, 65% din toate browserele care își accesează serverele erau compatibile cu HTTP / 1.1. Standardul HTTP / 1.1 definit în RFC  2068 a fost lansat oficial în ianuarie 1997. Îmbunătățirile și actualizările standardului HTTP / 1.1 au fost lansate în RFC  2616 în iunie 1999.

În 2007, Grupul de lucru HTTP a fost format, parțial, pentru a revizui și clarifica specificațiile HTTP / 1.1.

În iunie 2014, WG a lansat o specificație actualizată din șase părți, învechind RFC  2616 :

• RFC  7230 , HTTP / 1.1: Sintaxa mesajelor și rutare
• RFC  7231 , HTTP / 1.1: Semantică și conținut
• RFC  7232 , HTTP / 1.1: Cereri condiționate
• RFC  7233 , HTTP / 1.1: Cereri de interval
• RFC  7234 , HTTP / 1.1: cache
• RFC  7235 , HTTP / 1.1: Autentificare

În mai 2015, HTTP / 2 a fost publicat sub denumirea RFC  7540 .

Din 2016, mulți manageri de produse și dezvoltatori de agenți utilizator (browsere etc.) și servere web au început să planifice să renunțe treptat și să respingă suportul pentru protocolul HTTP / 0.9 , în principal din următoarele motive:

• este în mod clar învechit, deoarece este atât de simplu încât nimeni nu s-a deranjat nici măcar să scrie un document RFC (există doar documentul original);
• nu are anteturi HTTP și îi lipsesc și multe alte caracteristici care astăzi sunt într-adevăr necesare din motive minime de securitate;
• nu a fost folosit cu adevărat din 1999..2000 (din cauza HTTP / 1.0 și HTTP / 1.1);
• se pare că este folosit în mod aleatoriu doar de unele hardware de rețea foarte vechi, adică de routere etc.

În 2021, suportul HTTP / 0.9 este încă prezent în multe servere web și browsere (numai pentru răspunsurile serverului), deci nu este clar cât timp va dura această diseminare, poate că va fi finalizată mai întâi în agenții utilizator (browsere etc.) și apoi în servere web.

Sesiune HTTP

O sesiune HTTP este o secvență de tranzacții cerere-răspuns de rețea. Un client HTTP inițiază o solicitare prin stabilirea unei conexiuni TCP ( Transmission Control Protocol ) la un anumit port de pe un server (de obicei portul 80, ocazional portul 8080; consultați Lista numerelor de port TCP și UDP ). Un server HTTP care ascultă pe acel port așteaptă mesajul de solicitare al unui client. La primirea cererii, serverul trimite înapoi o linie de stare, cum ar fi „ HTTP / 1.1 200 OK ”, și un mesaj propriu. Corpul acestui mesaj este de obicei resursa solicitată, deși poate fi returnat și un mesaj de eroare sau alte informații.

Conexiuni persistente

În HTTP / 0.9 TCP / IP conexiunea este întotdeauna închisă după răspunsul serverului a fost trimis.

În HTTP / 1.0, așa cum se menționează în RFC 1945, TCP / IP conexiunea ar trebui să fie întotdeauna închise de către server după un răspuns a fost trimis. NOTĂ: de la sfârșitul anului 1996, unii dezvoltatori de browsere și servere populare HTTP / 1.0 (în special cei care au planificat și suport pentru HTTP / 1.1), au început să implementeze (ca extensie neoficială) un fel de mecanism de păstrare în viață (prin utilizarea anteturi HTTP noi) pentru a menține conexiunea TCP / IP deschisă pentru mai mult de o pereche de cerere / răspuns și astfel pentru a accelera schimbul de cereri / răspunsuri multiple.

În HTTP / 1.1 a fost introdus oficial un mecanism de păstrare a vieții, astfel încât o conexiune să poată fi reutilizată pentru mai multe cereri / răspunsuri. Astfel de conexiuni persistente reduc latența cererii în mod perceptibil, deoarece clientul nu are nevoie să renegocieze conexiunea TCP 3-Way-Handshake după ce a fost trimisă prima cerere. Un alt efect secundar pozitiv este că, în general, conexiunea devine mai rapidă în timp datorită mecanismului de pornire lentă a TCP .

HTTP / 1.1 a adăugat, de asemenea, canalizarea HTTP pentru a reduce și mai mult timpul de întârziere atunci când se utilizează conexiuni persistente, permițând clienților să trimită mai multe cereri înainte de a aștepta fiecare răspuns. Această optimizare nu a fost niciodată considerată cu adevărat sigură, deoarece câteva servere web și multe servere proxy , în special servere proxy transparente plasate în Internet / Intranet între clienți și servere, nu au gestionat corect cererile canalizate (au servit doar prima cerere aruncându-le pe celelalte sau au închis-o conexiunea deoarece au văzut mai multe date după prima solicitare etc.). În afară de aceasta, numai solicitările GET și HEAD ar putea fi canalizate într-un mod sigur și idempotent. După mulți ani de luptă cu problemele introduse prin activarea pipelining-ului, această caracteristică a fost mai întâi dezactivată și apoi eliminată din majoritatea browserelor, datorită adoptării anunțate a HTTP / 2.

HTTP / 2 a extins utilizarea conexiunilor persistente prin multiplexarea multor cereri / răspunsuri simultane printr-o singură conexiune TCP / IP.

HTTP / 3 nu utilizează conexiuni TCP / IP, ci UDP + QUIC pentru a evita problema congestionării TCP / IP a unei conexiuni.

Optimizări de recuperare a conținutului

În HTTP / 0.9 o resursă solicitată a fost întotdeauna trimisă în întregime.

HTTP / 1.0 a adăugat antete pentru a gestiona resursele stocate în cache de client pentru a permite cereri GET condiționate ; în practică, un server trebuie să returneze întregul conținut al resursei solicitate numai dacă ultima sa modificare a timpului nu este cunoscută de client sau dacă s-a schimbat de la ultimul răspuns complet la solicitarea GET.

HTTP / 1.0 a adăugat antetul „Content-Encoding” pentru a specifica dacă conținutul returnat al unei resurse a fost sau nu comprimat .

În HTTP / 1.0, dacă lungimea totală a conținutului unei resurse nu era cunoscută în prealabil (adică pentru că a fost generată dinamic etc.) atunci antetul "Content-Length: number"nu era prezent în anteturile HTTP și clientul presupunea că atunci când serverul a închis conexiunea , conținutul fusese trimis în totalitate. Acest mecanism nu a putut distinge între un transfer de resurse finalizat cu succes și unul întrerupt (din cauza unei erori de server / rețea sau altceva).

HTTP / 1.1 a adăugat noi antete pentru a gestiona mai bine recuperarea condiționată a resurselor cache.

HTTP / 1.1 a introdus codarea de transfer blocat pentru a permite transmiterea conținutului în bucăți pentru a-l trimite în mod fiabil chiar și atunci când serverul nu știe din timp lungimea acestuia (adică pentru că este generat dinamic etc.).

HTTP / 1.1 a adăugat, de asemenea , servirea intervalului de octeți , unde un client poate solicita doar una sau mai multe porțiuni (intervale de octeți) dintr-o resursă (adică prima parte, o parte în mijlocul sau la sfârșitul întregului conținut etc.) iar serverul trimite de obicei doar partea (părțile) solicitată (e). Acest lucru este util pentru a relua o descărcare întreruptă (atunci când un fișier este cu adevărat mare), când doar o parte a unui conținut trebuie afișată sau adăugată dinamic la partea deja vizibilă de către un browser (adică numai primul sau următoarele n comentarii ale o pagină web) pentru a economisi timp, lățime de bandă și resurse de sistem etc.

HTTP / 2 și HTTP / 3 au păstrat caracteristicile menționate mai sus ale HTTP / 1.1.

Starea sesiunii HTTP

HTTP este un protocol apatrid . Un protocol fără stat nu necesită ca serverul HTTP să păstreze informații sau stare despre fiecare utilizator pe durata mai multor cereri. Cu toate acestea, unele aplicații web implementează stări sau sesiuni de server folosind, de exemplu, cookie-uri HTTP sau variabile ascunse în formularele web .

Autentificare HTTP

HTTP oferă mai multe scheme de autentificare, cum ar fi autentificarea de acces de bază și autentificarea de acces digest, care funcționează printr-un mecanism de răspuns-provocare prin care serverul identifică și emite o provocare înainte de a difuza conținutul solicitat.

HTTP oferă un cadru general pentru controlul de acces și autentificare, printr-un set extensibil de scheme de autentificare provocare-răspuns, care pot fi utilizate de un server pentru a contesta o cerere a clientului și de către un client pentru a furniza informații de autentificare.

Tărâmuri de autentificare

Specificația de autentificare HTTP oferă, de asemenea, o construcție arbitrară, specifică implementării, pentru a împărți în continuare resursele comune unui anumit URI rădăcină . Șirul valoric al domeniului, dacă este prezent, este combinat cu URI rădăcină canonică pentru a forma componenta spațiului de protecție a provocării. De fapt, acest lucru permite serverului să definească domenii de autentificare separate sub un URI rădăcină.

Solicitați mesaje

Solicitați sintaxă

Un client trimite mesaje de solicitare către server, care constau din:

• o linie de solicitare, care constă din metoda de solicitare sensibilă la majuscule, un spațiu , ținta de solicitare, un alt spațiu, versiunea protocolului, o retur de transport și un flux de linie , de exemplu:

GET /images/logo.png HTTP/1.1

• zero sau mai multe câmpuri de antet de cerere (cel puțin 1 sau mai multe anteturi în cazul HTTP / 1.1), fiecare alcătuit din numele câmpului care nu face sensibilitate la majuscule, două puncte, spațiu alb principal opțional , valoarea câmpului, un spațiu alb opțional și se termină cu un returul transportului și o avansare de linie, de exemplu:

Host: www.example.com
Accept-Language: en

• o linie goală, care constă dintr-o întoarcere de trăsură și o alimentare de linie;
• un corp de mesaj opțional .

În protocolul HTTP / 1.1, toate câmpurile antetului cu excepția Host: hostnamesunt opționale.

O linie de solicitare care conține doar numele căii este acceptată de servere pentru a menține compatibilitatea cu clienții HTTP înainte de specificația HTTP / 1.0 din RFC  1945 .

Solicitați metode

O cerere HTTP / 1.1 făcută folosind telnet. Cerere mesaj de răspuns secțiunea antet, și corpul de răspuns sunt evidențiate.

HTTP definește metode (uneori denumite verbe , dar nicăieri în caietul de sarcini nu menționează verbul , nici OPȚIUNILE sau CAPUL nu este un verb) pentru a indica acțiunea dorită care trebuie efectuată asupra resursei identificate. Ceea ce reprezintă această resursă, fie că există date preexistente, fie că sunt generate dinamic, depinde de implementarea serverului. Adesea, resursa corespunde unui fișier sau ieșirii unui executabil care se află pe server. Specificația HTTP / 1.0 a definit metodele GET, HEAD și POST, iar specificația HTTP / 1.1 a adăugat cinci metode noi: PUT, DELETE, CONNECT, OPTIONS și TRACE. Fiind specificate în aceste documente, semantica lor este bine cunoscută și se poate depinde de ea. Orice client poate folosi orice metodă și serverul poate fi configurat pentru a suporta orice combinație de metode. Dacă o metodă este necunoscută unui intermediar, aceasta va fi tratată ca o metodă nesigură și neidentificată . Nu există nicio limită a numărului de metode care pot fi definite și acest lucru permite specificarea metodelor viitoare fără ruperea infrastructurii existente. De exemplu, WebDAV a definit șapte metode noi și RFC  5789 a specificat metoda PATCH .

Numele metodelor sunt sensibile la majuscule și minuscule. Acest lucru este în contrast cu numele câmpurilor antetului HTTP care nu disting majuscule și minuscule.

OBȚINE

Metoda GET solicită ca resursa țintă să transfere o reprezentare a stării sale. Solicitările GET ar trebui să recupereze doar date și nu ar trebui să aibă alt efect. (Acest lucru este valabil și pentru alte metode HTTP.) W3C a publicat principii de îndrumare cu privire la această distincție, spunând: „ Proiectarea aplicațiilor web ar trebui să fie informată de principiile de mai sus, dar și de limitările relevante”. Vedeți mai jos metodele sigure .

CAP

Metoda HEAD solicită ca resursa țintă să transfere o reprezentare a stării sale, ca pentru o solicitare GET, dar fără datele de reprezentare incluse în corpul de răspuns. Acest lucru este util pentru recuperarea metadatelor reprezentării în antetul de răspuns, fără a fi nevoie să transferați întreaga reprezentare.

POST

Metoda POST solicită ca resursa țintă să proceseze reprezentarea inclusă în cerere în funcție de semantica resursei țintă. De exemplu, este utilizat pentru postarea unui mesaj pe un forum pe Internet , pentru abonarea la o listă de discuții sau pentru finalizarea unei tranzacții de cumpărături online .

A PUNE

Metoda PUT solicită ca resursa țintă să creeze sau să își actualizeze starea cu starea definită de reprezentarea inclusă în cerere.

ȘTERGE

Metoda DELETE solicită ca resursa țintă să-și șteargă starea.

CONECTAȚI

Metoda CONNECT solicită ca intermediarul să stabilească un tunel TCP / IP către serverul de origine identificat de ținta cererii. Este adesea folosit pentru a securiza conexiunile prin unul sau mai multe proxy HTTP cu TLS . Consultați metoda CONNECT HTTP .

OPȚIUNI

Metoda OPTIONS solicită ca resursa țintă să transfere metodele HTTP pe care le acceptă. Aceasta poate fi utilizată pentru a verifica funcționalitatea unui server web solicitând „*” în locul unei resurse specifice.

URMĂ

Metoda TRACE solicită ca resursa țintă să transfere cererea primită în corpul de răspuns. În acest fel, un client poate vedea ce (dacă există) modificări sau adăugiri au fost făcute de intermediari.

PLASTURE

Metoda PATCH solicită ca resursa țintă să-și modifice starea în funcție de actualizarea parțială definită în reprezentarea inclusă în cerere.

Toate serverele HTTP de uz general sunt necesare pentru a implementa cel puțin metodele GET și HEAD, iar toate celelalte metode sunt considerate opționale de specificație.

Metode sigure

O metodă de solicitare este sigură dacă o cerere cu acea metodă nu are efectul intenționat asupra serverului. Metodele GET, HEAD, OPTIONS și TRACE sunt definite ca fiind sigure. Cu alte cuvinte, metodele sigure sunt destinate numai citirii . Totuși, acestea nu exclud efectele secundare , cum ar fi adăugarea informațiilor de solicitare într-un fișier jurnal sau încărcarea unui cont publicitar , deoarece acestea nu sunt solicitate de client, prin definiție.

În schimb, metodele POST, PUT, DELETE, CONNECT și PATCH nu sunt sigure. Acestea pot modifica starea serverului sau pot avea alte efecte, cum ar fi trimiterea unui e-mail . Astfel, astfel de metode nu sunt de obicei utilizate de roboții web sau crawlerele web conforme ; unele care nu se conformează tind să facă cereri fără a ține cont de context sau de consecințe.

În ciuda siguranței prescrise a cererilor GET , în practică gestionarea lor de către server nu este limitată din punct de vedere tehnic. Prin urmare, programarea neglijentă sau deliberată poate provoca modificări non-banale pe server. Acest lucru este descurajat, deoarece poate provoca probleme pentru cache-ul web , motoarele de căutare și alți agenți automatizați, care pot face modificări neintenționate pe server. De exemplu, un site web ar putea permite ștergerea unei resurse printr-o adresă URL precum https://example.com/article/1234/delete , care, dacă ar fi preluată în mod arbitrar, chiar și folosind GET , ar șterge pur și simplu articolul.

Un exemplu de acest loc , în practică , a fost în timpul trăit scurt Google Web Accelerator beta , care preîncărcate URL - uri arbitrare pe pagina unui utilizator a fost de vizionare, cauzând înregistrări care urmează să fie modificate sau șterse în mod automat în masă . Beta a fost suspendată la doar câteva săptămâni după prima sa lansare, în urma unor critici pe scară largă.

Metode idempotente

O metodă de solicitare este idempotentă dacă mai multe cereri identice cu acea metodă au același efect intenționat ca o singură astfel de cerere. Metodele PUT și DELETE și metodele sigure sunt definite ca idempotente.

În schimb, metodele POST, CONNECT și PATCH nu sunt neapărat idempotente și, prin urmare, trimiterea unei cereri POST identice de mai multe ori poate modifica în continuare starea serverului sau poate avea efecte suplimentare, cum ar fi trimiterea unui e-mail . În unele cazuri, acest lucru poate fi de dorit, dar în alte cazuri, acest lucru se poate datora unui accident, cum ar fi atunci când un utilizator nu realizează că acțiunea lor va duce la trimiterea unei alte cereri sau când nu a primit feedback adecvat că prima lor solicitare a fost de succes. În timp ce browserele web pot afișa casete de dialog de alertă pentru a avertiza utilizatorii în unele cazuri în care reîncărcarea unei pagini poate retrimite o cerere POST, este, în general, sarcina aplicației web să gestioneze cazurile în care o cerere POST nu ar trebui trimisă de mai multe ori.

Rețineți că protocolul sau serverul web nu impun dacă o metodă este idempotentă. Este perfect posibil să scrieți o aplicație web în care (de exemplu) o inserție de bază de date sau altă acțiune neidentificată este declanșată de o solicitare GET sau de altă natură. Cu toate acestea, ignorarea acestei recomandări poate duce la consecințe nedorite, dacă un agent utilizator presupune că repetarea aceleiași cereri este sigură atunci când nu este.

Metode cache

O metodă de solicitare este cache dacă răspunsurile la solicitări cu această metodă pot fi stocate pentru reutilizare viitoare. Metodele GET, HEAD și POST sunt definite ca fiind cache.

În schimb, metodele PUT, DELETE, CONNECT, OPTIONS, TRACE și PATCH nu sunt cache.

Solicitați câmpuri de antet

Câmpurile antet cerere permit clientului să treacă informații suplimentare dincolo de linia de cerere, acționând ca modificatori ai cererii (similar cu parametrii unei proceduri). Acestea oferă informații despre client, despre resursa țintă sau despre gestionarea așteptată a cererii.

Mesaje de răspuns

Sintaxa răspunsului

Un server trimite mesaje de răspuns către client, care constau din:

• o linie de stare, constând din versiunea protocolului, un spațiu , codul de stare a răspunsului , un alt spațiu, o frază motiv posibil goală, o retur de transport și un flux de linie , de exemplu:

HTTP/1.1 200 OK

• zero sau mai multe câmpuri de antet de răspuns , fiecare alcătuit din numele câmpului fără majuscule, două puncte, spațiu liber opțional , valoarea câmpului, un spațiu opțional opțional și care se termină cu un retur de căruță și un avans de linie, de exemplu:

Content-Type: text/html

• o linie goală, care constă dintr-o întoarcere de trăsură și o alimentare de linie;
• un corp de mesaj opțional .

Coduri de stare de răspuns

În HTTP / 1.0 și de atunci, prima linie a răspunsului HTTP se numește linie de stare și include un cod de stare numeric (cum ar fi „ 404 ”) și o frază motivală textuală (cum ar fi „Nu a fost găsit”). Codul de stare a răspunsului este un cod întreg din trei cifre care reprezintă rezultatul încercării serverului de a înțelege și satisface cererea corespunzătoare a clientului. Modul în care clientul gestionează răspunsul depinde în primul rând de codul de stare și, în al doilea rând, de celelalte câmpuri ale antetului de răspuns. Este posibil ca clienții să nu înțeleagă toate codurile de stare înregistrate, dar trebuie să înțeleagă clasa lor (dată de prima cifră a codului de stare) și să trateze un cod de stare nerecunoscut ca fiind echivalent cu codul de stare x00 al acelei clase.

Expresiile motivare standard sunt doar recomandări și pot fi înlocuite cu „echivalenți locali” la discreția dezvoltatorului web . Dacă codul de stare a indicat o problemă, agentul utilizator ar putea afișa expresia motivului utilizatorului pentru a furniza informații suplimentare despre natura problemei. Standardul permite, de asemenea, agentului utilizator să încerce să interpreteze expresia motivului , deși acest lucru ar putea fi neînțelept, deoarece standardul specifică în mod explicit că codurile de stare pot fi citite de mașină și expresiile motiv sunt citibile de către om.

Prima cifră a codului de stare definește clasa sa:

1XX (informativ)

Solicitarea a fost primită, continuând procesul.

2XX (de succes)

Solicitarea a fost primită, înțeleasă și acceptată cu succes.

3XX (redirecționare)

Trebuie luate măsuri suplimentare pentru a finaliza cererea.

4XX (eroare client)

Solicitarea conține o sintaxă greșită sau nu poate fi îndeplinită.

5XX (Eroare de server)

Serverul nu a reușit să îndeplinească o cerere aparent validă.

Câmpuri de antet de răspuns

Câmpurile de antet de răspuns permit serverului să transmită informații suplimentare dincolo de linia de stare, acționând ca modificatori de răspuns. Acestea oferă informații despre server sau despre accesul ulterior la resursa țintă sau resursele conexe.

Fiecare câmp de antet de răspuns are un sens definit, care poate fi rafinat în continuare prin semantica metodei de solicitare sau codul de stare a răspunsului.

Conexiuni criptate

Cel mai popular mod de a stabili o conexiune HTTP criptată este HTTPS . Există și alte două metode pentru stabilirea unei conexiuni HTTP criptate: Protocol de transfer securizat hipertext și utilizarea antetului de actualizare HTTP / 1.1 pentru a specifica o actualizare la TLS. Cu toate acestea, suportul browserului pentru aceste două este aproape inexistent.

Exemplu de sesiune

Mai jos este un exemplu de conversație între un client HTTP și un server HTTP care rulează pe www.example.com , portul 80.

Cererea clientului

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

O cerere de client (care constă în acest caz din linia de cerere și câteva anteturi care pot fi reduse doar la "Host: hostname"antet) este urmată de o linie necompletată, astfel încât cererea să se încheie cu un capăt dublu de linie, fiecare sub forma unui returul carului urmat de un avans de linie . Valoarea "Host: hostname"antetului face distincție între diferite nume DNS care partajează o singură adresă IP , permițând găzduirea virtuală bazată pe nume . Deși este opțional în HTTP / 1.0, este obligatoriu în HTTP / 1.1. (Un „/” (bară) va prelua de obicei un fișier /index.html dacă există unul.)

Răspunsul serverului

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

Câmpul de antet ETag (etichetă entitate) este utilizat pentru a determina dacă o versiune cache a resursei solicitate este identică cu versiunea curentă a resursei de pe server. "Content-Type"specifică tipul mediului de internet al datelor transmise de mesajul HTTP, în timp ce "Content-Length"indică lungimea acestuia în octeți. Serverul web HTTP / 1.1 își publică capacitatea de a răspunde la cererile pentru anumite intervale de octeți ai documentului prin setarea câmpului "Accept-Ranges: bytes". Acest lucru este util, dacă clientul trebuie să aibă doar anumite porțiuni dintr-o resursă trimisă de server, care se numește servirea de octeți . Când "Connection: close"este trimis, înseamnă că serverul web va închide conexiunea TCP imediat după încheierea transferului acestui răspuns.

Majoritatea liniilor de antet sunt opționale, dar unele sunt obligatorii. Atunci când antetul "Content-Length: number"lipsește într-un răspuns cu un corp de entitate, atunci acesta ar trebui considerat o eroare în HTTP / 1.0, dar poate să nu fie o eroare în HTTP / 1.1 dacă antetul "Transfer-Encoding: chunked"este prezent. Codificarea de transfer blocat utilizează o dimensiune a bucății de 0 pentru a marca sfârșitul conținutului. Unele implementări vechi ale HTTP / 1.0 au omis antetul "Content-Length"atunci când lungimea entității corpului nu era cunoscută la începutul răspunsului și astfel transferul de date către client a continuat până când serverul a închis socketul.

A poate fi folosit pentru a informa clientul că partea entității corpului din datele transmise este comprimată de algoritmul gzip. "Content-Encoding: gzip"

Protocoale similare

• Protocolul Gopher este un protocol de livrare de conținut , care a fost înlocuit de HTTP la începutul anilor 1990.
• SPDY Protocolul este o alternativă la HTTP dezvoltat la Google , înlocuit prin HTTP / 2 .
• Protocolul Gemeni este un protocol Gopher-inspirat , care impune caracteristici legate de viața privată.

Vezi si

• Compararea protocoalelor de transfer de fișiere
• Protocol de aplicare constrâns - un protocol semantic similar cu HTTP, dar utilizează mesaje UDP sau UDP, precum destinate dispozitivelor cu capacitate limitată de procesare; reutilizează HTTP și alte concepte de internet, cum ar fi tipul de internet media și legarea web (RFC 5988)
• Negocierea conținutului
• Autentificare acces digest
• Compresie HTTP
• HTTP / 2 - dezvoltat de grupul de lucru IETF Hypertext Transfer Protocol (httpbis)
• Lista câmpurilor antet HTTP
• Lista codurilor de stare HTTP
• Transfer de stat reprezentativ (REST)
• Obiectul variantei
• Cache web
• WebSocket

Referințe

linkuri externe

• „Istoricul modificărilor pentru HTTP” . W3.org . Adus 01/08/2010 . Un istoric tehnic detaliat al HTTP.
• „Probleme de proiectare pentru HTTP” . W3.org . Adus 01/08/2010 . Probleme de proiectare de Berners-Lee când el proiecta protocolul.
• HTTP 0.9 - Implementat în 1991