Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) este metoda cea mai des utilizată pentru accesarea informațiilor în Internet care sunt păstrate pe servere World Wide Web (WWW). Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu conține partea de protocol, aceasta se consideră ca fiind http. HTTP presupune că pe calculatorul destinație rulează un program care înțelege protocolul. Fișierul trimis la destinație poate fi un document HTML (abreviație de la HyperText Markup Language), un fișier grafic, de sunet, animație sau video, de asemenea un program executabil pe server-ul respectiv sau și un editor de text. După clasificarea după modelul de referință OSI, protocolul HTTP este un protocol de nivel aplicație. Realizarea și evoluția sa este coordonată de către World Wide Web Consortium (W3C).

Modul de funcționare

HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un computer aflat la distanță spre propriul computer. Dacă se apelează un link sau o adresă de web cum ar fi http://www.example.com, atunci se cere calculatorului host să afișeze o pagină web (index.html sau altele). În prima fază numele (adresa) www.example.com este convertit de protocolul DNS într-o adresă IP. Urmează transferul prin protocolul TCP pe portul standard 80 al serverului HTTP, ca răspuns la cererea HTTP-GET. Informații suplimentare ca de ex. indicații pentru browser, limba dorită ș.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în (X)HTML, cu fișiere atașate ca imagini, fișiere de stil (CSS), scripturi (Javascript), dar pot fi și pagini generate dinamic (SSI, JSP, PHP și ASP.NET). Dacă dintr-un anumit motiv informațiile nu pot fi transmise, atunci serverul trimite înapoi un mesaj de eroare. Modul exact de desfășurare a acestei acțiuni (cerere și răspuns) este stabilit în specificațiile HTTP.

Transferul argumentelor

Deseori utilizatorul dorește să transmită informații speciale la website. Aici HTTP pune la dispozitie două posibilități:

Transferul datelor în combinație cu o cerere pentru o resursă (HTTP-metoda "GET")
Transferul datelor în combinație cu o cerere specială (HTTP-metoda "POST")

Datele transferate vin deseori %-codate. La metoda GET se utilizează partea de cerere Uniform Resource Identifiers (URI) cu simbolul ?. Această metodă se utilizează pentru a transfera o listă de parametri, pe care partea opusă trebuie să o ia în considerare la prelucrarea cererii.

Deseori această listă cuprinde perechi de valori separate prin semnul &, care sunt alcătuite din numele parametrului, semnul = și valoarea parametrului. Rareori se mai utilizează și semnul ; pentru separarea înregistrărilor listei [1].

Exemplu: la pagina de start de la Wikipedia.ro utilizatorul introduce în câmpul de căutare termenul "pisici", alege categoria "articole" și apasă butonul de căutare. Atunci browserul trimite următoarea cerere la server:

GET /wiki/special:Search?search=pisici&go=articol HTTP/1.1 Host: ro.wikipedia.org ...

Serverului Wikipedia îi sunt transmise două perechi de valori: Argument Valoare search pisici go articol

Perechile de valori se transmit sub forma

Argument1=valoare1&Argument2=valoare2

iar cu ? se atașează pagina. Astfel serverul află că utilizatorul dorește să vadă articole despre pisici. Serverul prelucrează cererea, dar nu trimite un fișier ci redirecționează browserul cu un Location-Header spre pagina dorită:

HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:12:44 GMT Location: http://ro.wikipedia.org/wiki/pisici ... Browserul execută indicația și, pe baza noilor informații, emite o nouă cerere: GET /wiki/pisici HTTP/1.1 Host: ro.wikipedia.org ... Serverul răspunde și oferă pagina cu articole despre pisici:

HTTP/1.0 200 OK Date: Fri, 13 Jan 2008 15:12:48 GMT Last-Modified: Tue, 10 Jan 2008 11:18:20 GMT Content-Language: ro Content-Encoding: gzip Content-Type: text/html; charset=utf-8

.‹........´ZKs.¹.>Û¿.ž-[¶KÃ!õ²ÌÇlô²¬¬ìuVò*ÉÖ– 3.r`Î+.F”xÊ!ÿ ×.ý.ö´7ý“ü’t.ó"9ÔÊ›Ä®.A.ÐÝ

Partea de date este mai lungă și de necitit din cauza compresiei gzip.

În cazul unei cereri POST variabilele nu se află în URI, ci în partea body:

POST /wiki/special:Search HTTP/1.1 Host: ro.wikipedia.org Content-Type: application/x-www-form-urlencoded Content-Length: 24

search=pisici&go=articol

Serverul răspunde astfel : HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:32:43 GMT Location: http://ro.wikipedia.org/wiki/pisici

Coduri de raspuns HTTP (Http Response Code)

Codurile de stare al raspunsurilor HTTP sunt clasificate în 5 clase (categorii). Acestea sunt (pentru fiecare clasa sunt date câteva dintre erorile conținute):

1xx - erori informaționale: această clasă a status-ului indică un răspuns provizoriu al serverului și conține numai linia de status (de răspuns) sau alte aplicații opționale. Nu sunt aplicații necesare pentru acestă clasa de răspuns/status. Aceste status-uri pot fi ignorate.

100 - continuă:
Utilizatorul ar trebui să își continue cererea/acțiunea. Acest răspuns provizoriu este folosit pentru a informa utilizatorul că partea inițială a cererii a fost receptată și că deocamdată nu a fost refuzată de server. Utilizatorul ar trebui să continue și să ignore acest răspuns.

101 - schimbare protocol:
Server-ul înțelege și are intenția de a de a îndeplini cererea utilizatorului, răspunând prin această eroare că părți ale server-ului sunt în proces de schimbare/mutare. Server-ul va schimba protocolul imediat după ce răspunsul pentru linia 101 va fi terminată. Protocolul ar trebui schimbat doar în momentul în care acest lucru este avantajos și se permite.

2xx - răspuns reușit: clasa de răspuns/status ce indică utilizatorului că cererea a fost primită, înțeleasă și acceptată cu succes.

200 - ok:
Această cerere a fost executată cu succes. Informația a revenit cu un răspuns pozitiv, indiferent de modul în care s-a făcut cererea.

201 - creat/realizat:
Cererea a fost îndeplinită având ca rezultat crearea unui nou rezultat. Noul rezultat poate fi referit/raportat de către URI-uile înapoiate la intrarea răspunsului.

202 - acceptat:
Cererea a fost acceptata pentru procesare, dar aceasta din urmă nu a fost terminată complet. Scopul acestui mesaj este de a permite unui server să accepte cereri de la alți utilizatori, fără a cere conexiunii clientului să insiste până ce procesul/cererea e completă.

203 - informație neautorizată:
Informația returnată/revenită nu e definitivă ca fiind din server-ul principal, ci e adunata/receptionata de la un server local.

204 - fara continut:
Server-ul a indeplinit cererea si nu e nevoit sa intoarca raspunsul, dar ar dori sa raspunda printr-o informație recentă, gen meta.

205 - conținut refăcut:
Cererea a fost îndeplinita și ar trebui ca browser-ul să poată modifica/reseta modul de vizualizare a documentului ce a cauzat această cerere către server.

206 - conținut parțial:
Serverul a îndeplinit parțial cererea de primire de la sursă.

3xx - redirecționări: această clasă de răspuns/status indică faptul că acțiunile următoare vor trebui făcute de browser pentru a putea fi îndeplinita cererea. Cererea ar putea fi direcționată de browser fără a interacționa cu utilizatorul dacă și numai dacă metoda folosită în cea de a doua cerere este „Primit/recepționat” sau „Direcționat/condus”.

300 - diferite/multiple alegeri:
Sursa cererii corespunde unor seturi de descrieri, fiecare cu locații specifice, iar browser-ul - dat fiind negocierea informașiei, primețte răspunsul astfel încât utilizatorul/browser-ul să poată alege modul dorit astfel încât redirecționarea să fie spre acea locație. În cazul în care cererea a fost de tip „Condus/trimis”, răspunsul ar trebui să includă o intrare cu lista caracteristicilor și locațiilor de unde utilizatorul sau browser-ul poate alege sursa cea mai apropiată.

301 - modificat/mutat permanent:
Cererii i-a fost atribuite o sursă nouă și permanentă URI iar cererile următoare ar trebui să folosească una din sursele returnate URI. Dacă acest mesaj/cod este primit ca răspuns al unei cereri tip „Primit/recepționat” sau „Direcționat/condus”, browser-ul nu trebuie să redirecționeze automat cererea, doar dacă nu poate fi confirmată de către utilizator.

302 - găsit:
Sursa cererii este temporar pe un alt URI. În cazul în care redirecționarea ar putea fi schimbată ocazional, utilizatorul ar trebui să folosească în continuare cererea URI (Request-URI) în cazul unor cereri ulterioare.
Dacă mesajul/statusul 302 este recepționat ca răspuns al unei cereri alta decât „Primit/recepționat” sau „Direcționat/condus”, browser-ul nu trebuie să redirecționeze automat cererea dacă aceasta nu poate fi confirmată de cărte utilizator.

303 - vezi alta sursă:
Răspunsul cererii poate fi găsit sub un diferit URI și ar trebui să fie recepționat folosind metoda „Primit/recepționat” de la acea sursă.

304 - nemodificat:
În cazul în care clientul a efectuat o cerere de tip „Primit/recepționat” și accesul este permis, dar documentul nu a fost modificat, serverul ar trebui să răspundă cu acest mesaj/status.

305 - folosește proxy:
Cererea trebuie accesată printr-un proxy dat de către câmpul de locație. Acesta este dat de către URI. Beneficiarul va repeta acestă unică cerere prin intermediul unui proxy. Răspunsul 305 va fi generat doar de către serverul de origine.

306 (nefolosit):
Acest mesaj/status a fost folosit într-o vesiune anterioară a specificațiilor deci nu mai este folosit, el fiind reținut.

307 - redirecționare temporară:
Sursa cerută se află temporar la un diferit URI. Din moment ce redirecționarea poate fi modificata ocazional, utilizatoarul ar trebui să continuie să folosească URI-ul cerut pentru viitoarele acțiuni.

4xx - erori ale utilizatorilor: această clasă de mesaje/statusuri este folosită în cazurile în care utilizatorul ar putea greși formularea cererii. Excepția fiind răspunsurule pentru cererile tip „Direcționat/condus”, atunci serverul ar trebui să conțină o intrare cu o explicație a situației erorii și dacă e o eroare temporară sau pemanentă. Aceste răspunsuri sunt aplicabile pentru orice fel de cerere. Browser-ele ar trebui să arate orice intrare cerută de utilizator.

400 - cerere greșită:
Cererea nu a putut fi înțeleasă/percepută de către server din cauza unei sintaxe greșite/incomplete. Utilizatorul ar trebui să nu repete cererea fără ca aceasta să suporte modificări.

401 - neautorizat:
Cererea necesită autentificarea/înregistrarea utilizatorului. Răspunsul trebuie să includă WWW - câmp de autentificare conținând o somație aplicabilă utilizatorului. Utilizatorul poate repeta cererea. Dacă cererea deja includea câmpul de autorizare, atunci raspunsul 401 indică faptul că autorizarea a fost refuzată. Dacă răspunsul 401 conține aceeași somație ca răspuns principal iar browser-ul a executat autentificarea cel puțin o dată, atunci utilizatorul ar trebui să i se prezinte intrarea dată în răspuns, din moment ce aceasta include informații relevante.

402 - necesită plata:
Rezervat pentru utilizare ulterioară.

403 - interzis:
Serverul a înțeles cererea, dar refuză să o îndeplinească. Autorizarea nu ajută în nici un caz, iar cererea nu ar mai trebui repetata.

404 - negăsit:
Serverul nu a găsit nimic care să corespundă cererii URI. Nu se dau indicații despre condiția temporară sau permanentă.

405 - metodă nepermisă:
Metoda specificată în linia de cerere (Request-Line) nu este permisă de către sursa identificată după URI-ul cerut.

406 - neacceptat:
Sursa identificată de cerere este capabilă să genereze doar intrări care au conținut specific neacceptat de către condițiile de acceptare trimise prin cerere.

407 - autentificare prin proxy:
Mesajul este similar celui 401, dar indică situația în care utilizatorul trebuie să se autentifice prin proxy.

408 - cerere expirată:
Utilizatorul nu a făcut cererea în timpul în care serverul era pregătit sa o aștepte. Se poate repeta cererea fără modificări prealabile.

5xx - erori de server: răspunsurile/status-urile ce încep cu unitatea/cifra 5 indică cazurile în care serverul e conștient de greșelile produse sau e incapabil să execute cererea. Excepție facând răspunsul unei cereri „Direcționat/condus”, serverul ar trebui, în acest caz sa includă o afișare cu o explicație a situației de eroare, fie că e temporara sau permanentă.

500 - eroare internă de server:
Server-ul a întâmpinat o condiție neașteptată și o previne spre a putea îndeplini cererea.

501 - neîndeplinit/nerecunoscut:
Server-ul nu poate suporta funcționalitatea cerută pentru a putea îndeplini cererea. Acesta este răspunsul specific în cazurile în care server-ul nu recunoaște metoda de cerere și nu e capabil să o suporte indiferent de mijloc/resursă.

502 - poartă/ieșire greșită:
Server-ul, în timp ce încerca să se comporte ca o poartă/ieșire sau ca un proxy, a recepționat un răspuns invalid de la un server de deasupra/anterior în încercarea de a îndeplini cererea.

503 - serviciu nedisponibil:
În prezent server-ul nu poate să se ocupe de cererile trimise din cauza unei supraîncărcări sau a serviciilor de întreținere a server-ului ce au loc în acel moment. Aceasta este o stare temporară și în curând va fi remediată.

504 - poartă/ieșire expirată:
Server-ul, în timp ce încerca să se comporte ca o poartă/ieșire sau ca un proxy, nu a primit un răspuns la timp de la serverele de deasupra/anterioare lui specificat de URI (ex. HTTP, FTP, LDAP) sau de la un server auxiliar (ex. DNS) necesar accesării în încercarea de a termina/îndeplini cererea.

505 - versiunea HTTP nu e suportată/susținută:
Serveru-l nu suportă sau refuză să suporte versiunea de protocol a HTTP ce a fost folosită în formularea cererii. Server-ul sugerează că e incapabil să completeze/termine cererea folosind aceeași versiune cu cea a clientului.

Versiuni

HTTP/0.9 - prima versiune realizată de Tim Berners-Lee și echipa sa. Această versiune este foarte simplă, dar cu numeroase neajunsuri, fiind repede înlocuită de alte versiuni;
HTTP/1.0 – versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătățiri;
HTTP/1.1 – versiune de îmbunătățire și reparare a neajunsurilor versiunilor anterioare.

În prezent se utilizează două versiuni ale protocolului, HTTP/1.0 și HTTP/1.1. La versiunea HTTP/1.0 se stabilește o nouă conexiune TCP înaintea cererii, iar după transmiterea răspunsului conexiunea trebuie închisă. Astfel dacă un document HTML cuprinde 10 imagini, vor fi necesare 11 conexiuni TCP, pentru ca pagina să fie afișată complet (în browser). La versiunea 1.1 se pot emite mai multe cereri și răspunsuri pe aceeași conexiune TCP. Astfel pentru documentul HTML cu 10 imagini este necesară doar o singură conexiune TCP. Deoarece - datorită algoritmului Slow-Start - viteza conexiunii TCP este la început mică, dar acum el e necesar doar o singură dată, se scurtează semnificativ durata totală de încărcare a paginii. La aceasta se adaugă și faptul că versiunea 1.1 poate relua și continua transferuri întrerupte.

La HTTP se pierd informațiile cererilor vechi (deci este un protocol fără reținerea stării). Prin utilizarea de cooki-uri în header, se pot realiza însă aplicații care pot utiliza informații de stare (opțiunile utilizatorului din sesiunea actuală, coș de cumpărături ș.a.). Chiar și o recunoaștere a utilizatorului este astfel posibilă. În mod normal se pot citi informațiile transmise care parcurg rețeaua pe computere și rutere. Prin HTTPS transferul se poate și cripta.

Versiunea cea mai recentă se poate utiliza în chat-uri prin utilizarea MIME-tip-ului multipart/replace, care reînnoiește complet conținutul ferestrei browser-ului. Noua versiune permite pe lângă preluarea datelor, și transmiterea lor la server. Cu ajutorul metodei "PUT" web-designerii pot să-și publice paginile web pe webserver prin WebDAV, iar prin metoda "DELETE" ei pot chiar și șterge pagini de pe server.

De asemenea, HTTP/1.1 mai oferă metoda "TRACE" prin care se poate urmări calea spre webserver, și verifica dacă datele au fost corect transferate. Astfel se poate urmări calea prin diferite proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicație.

Metode

Metodele disponibile sunt :

GET: este cea mai folosită metodă, fiind utilizată atunci când serverului i se cere o resursă.
HEAD: se comportă exact ca metoda GET, dar serverul returnează doar antetul resursei, ceea ce permite clientului să inspecteze antetul resursei, fără a fi nevoit să obțină și corpul resursei.
PUT: metoda este folosită pentru a depune documente pe server, fiind inversul metodei GET.
POST: a fost proiectată pentru a trimite date de intrare către server.
DELETE: este opusul metodei PUT.
TRACE: este o metodă folosită de obicei pentru diagnosticare, putând da mai multe informații despre traseul urmat de legătura HTTP, fiecare server proxy adăugându-și semnătura în antetul Via.
OPTIONS: este folosită pentru identificarea capacităților serverului Web, înainte de a face o cerere.
CONNECT: este o metodă folosită în general de serverele intermediare.

Exemplu

Cererea clientului:

GET / HTTP/1.1
Host: www.example.com

Răspunsul serverului:

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

Legături externe

Commons

Wikimedia Commons conține materiale multimedia legate de HTTP

HTTP 0.9 – As Implemented in 1991
„Change History for HTTP”. W3.org. Accesat în 1 august 2010. A detailed technical history of HTTP.
„Design Issues for HTTP”. W3.org. Accesat în 1 august 2010. Design Issues by Berners-Lee when he was designing the protocol.
„Classic HTTP Documents”. W3.org. 14 mai 1998. Accesat în 1 august 2010. list of other classic documents recounting the early protocol history

Suită de protocoale de Internet
nivelul aplicație^⁠(d)
BGP DHCP DHCPv6^⁠(d) DNS FTP HTTP IMAP IRC LDAP MGCP NNTP NTP POP ONC/RPC^⁠(d) RTP RTSP RIP SIP SMTP SNMP^⁠(d) SOCKS^⁠(d) SSH Telnet TLS/SSL XMPP^⁠(d)
nivelul transport^⁠(d)
TCP UDP DCCP^⁠(d) SCTP^⁠(d) RSVP^⁠(d)
nivelul internet^⁠(d)
IP IPv4 IPv6 ICMP ICMPv6^⁠(d) ECN^⁠(d) IGMP^⁠(d) IPsec
nivelul legătură^⁠(d)
ARP/InARP^⁠(d) NDP^⁠(d) OSPF Tunnels^⁠(d) L2TP^⁠(d) PPP^⁠(d) MAC^⁠(d) Ethernet DSL ISDN FDDI^⁠(d) DOCSIS
v d m