Ichim Cezar Alexandru IB

SCOALA POSTLICEALA GHEORGHE MARZESCU

TEMA
PROTOCOLUL HTTP

1. PROTOCOLUL HTTP
1

TERMINOLOGIE

HTTP - Hypertext Transfer Protocol .World Wide Web este alctuit din documente care folosesc un
limbaj de formatare denumit HTML, abreviere de la Hypertext Markup Language (limbaj de
marcare prin hipertext). Aceste documente sunt compuse din text de afiat, imagini grafice, comenzi
de formatare i hiperlegturi spre alte documente situate altundeva n Web. Documentele HTML
sunt afiate cel mai frecvent folosind browsere Web, precum Internet Explorer, Safari sau Mozilla
Firefox.
Un protocol denumit Hypertext Transfer Protocol (protocol de transfer prin hipertext)
controleaz tranzaciile dintre un client Web i un server Web. HTTP este un protocol destinat
stratului aplicaie. Protocolul HTTP face uz n mod transparent de DNS i de alte protocoale
Internet pentru a forma conexiuni ntre clientul i serverul Web astfel nct utilizatorul cunoate
numai numele domeniului i numele documentului nsui.
HTTP este, n esen, un protocol nesigur. Informaiile pe suport text sunt transmise n clar",
ntre client i server. Pentru a satisface necesitatea unor reele Web sigure exist alternative precum
Secure HTTP (S-HTTP) sau Secure Sockets Layer (SSL).
Cererile unui client Web ctre un server Web sunt orientate spre conexiune, deci sunt persistente.
Odat ce clientul a primit coninutul unei pagini HTML, conexiunea nu mai este activ. Executarea
unui clic n documentul HTML reactiveaz legtura fie ctre serverul original (dac ntr-acolo
indic hiperlegtura), fie ctre un alt server, situat altundeva.
Vor fi folosii n cele ce urmeaz urmtorii termeni:
-conexiune
Un circuit virtual la nivelul transport stabilit ntre doua programe care doresc sa comunice.
-mesaj
Unitatea de baza a unei comunicaii HTTP, constnd dintr-o secven structurata de octei,
transmisia printr-o conexiune.
-cerere
Un mesaj de cerere HTTP
-rspuns
Un mesaj de rspuns HTTP.

-resursa
Un obiect de date sau serviciu care poate fi identificat de un URI. Resursele pot avea reprezentri
multiple (e.g. formate, mrimi, rezoluii, etc.).
-entitate
Informaia transferat ntr-o operaie de cerere sau de rspuns. O entitate cuprinde att metainformaii, ct si coninutul propriu-zis.
-reprezentare
O entitate inclusa ntr-un rspuns ce reprezint o negociere ntre client si server.
-negociere
Mecanism de selectare a reprezentrii potrivite a unei date solicitate.
-client
Un program care stabilete conexiuni cu scopul de a trimite cereri.
-agent-utilizator
Clientul ce iniiaz o cerere (navigator, editor, robot de traversare Web). Navigatoarele cele mai
cunoscute sunt Netscape Navigator, Internet Explorer, Arena, Mozaic.
-Server
O aplicaie care accepta conexiuni, rspunznd la anumite cereri transmise de clien i. Un
program poate juca rol att de server, ct si de client. Un server se poate comporta ca server ini ial,
poarta, tunel sau Proxy Web n funcie de natura cererii. Cele mai cunoscute servere Web sunt:
Apache, Netscape Enterprise Server, Sun Web Server, Windows NT Web Server, Stronghold.
-Proxy (intermediar)
Un program intermediar care ruleaz ca server, ct si drept client pentru a transmite cereri altor
servere. Cererile trimise unui Proxy pot fi rezolvate intern sau transmise mai departe, ctre alte

servere (posibil translatate). Un proxy trebuie sa implementeze cerin ele de server si de client ale
specificaiei HTTP.
-poarta
Un server care lucreaz ca intermediar pentru alte servere, n mod transparent, fiind si un translator
de protocoale.
-tunel
Un program intermediar funcionnd ca mijlocitor ntre doua conexiuni.
-cache
Un depozit local de memorare a mesajelor (datelor) de rspuns si un subsistem de control al
acestuia. Memoria cache reduce timpul de rspuns si congestia re elei. Orice client si server poate
include un cache.

1.2 STRUCTURA UNUI SERVER WEB SUB LINUX. MODUL DE

FUNCIONARE

n figura urmtoare se va ilustra structura unui server Web sub Linux:

HTTP

ofer o tehnic

de comunicare

prin

paginile

web

se

pot

transmite de la

un

computer

aflat

distan

la

care

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 afieze 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
rspuns la cererea HTTP-GET. Informaii suplimentare ca de ex. indicaii pentru browser, limba
dorit .a. se pot aduga n header-ul (antetul) pachetului HTTP. n urma cererii HTTP-GET
urmeaz din partea serverului rspunsul cu datele cerute, ca de ex.: pagini n (X)HTML, cu fiiere
ataate ca imagini, fiiere de stil (CSS), scripturi (Javascript), dar pot fi i pagini generate dinamic
(SSI, JSP, PHP i ASP.NET). Dac dintr-un anumit motiv informaiile nu pot fi transmise, atunci
serverul trimite napoi un mesaj de eroare. Modul exact de desfurare a acestei aciuni (cerere i
rspuns) este stabilit n specificaiile HTTP.

1.3.TRANSFERUL ARGUMENTELOR
Deseori utilizatorul dorete s transmit informaii speciale la website. Aici HTTP pune la
dispoziie dou posibiliti:

Transferul datelor n combinaie cu o cerere pentru o resurs (HTTP-metoda "GET")

Transferul datelor n combinaie 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 alctuite din
numele parametrului, semnul = i valoarea parametrului. Rareori se mai utilizeaz i semnul ;
pentru separarea nregistrrilor listei .
Exemplu: la pagina de start de la Wikipedia.ro utilizatorul introduce n cmpul de cutare
termenul "pisici", alege categoria "articole" i apas butonul de cutare. Atunci browserul trimite
urmtoarea 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 ataeaz pagina. Astfel serverul afl c utilizatorul dorete s vad articole despre pisici.
Serverul prelucreaz cererea, dar nu trimite un fiier ci redirecteaz browserul cu un LocationHeader 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 indicaia i, pe baza noilor informaii, emite o nou cerere: GET /wiki/pisici
HTTP/1.1 Host: ro.wikipedia.org. Serverul rspunde 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 ContentType: text/html; charset=utf-8 .........ZKs..>.-[K!luV*
3.r`+.Fx! ..7t."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 rspunde astfel:

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

1.4.ERORI DE HTTP
Erorile de HTTP sunt clasificate n 5 clase (categorii). Acestea sunt (pentru fiecare clasa sunt
date cteva dintre erorile coninute):
-1xx - erori informaionale: aceast clas a status-ului indic un rspuns provizoriu al
serverului i conine numai linia de status (de rspuns) sau alte aplicaii opionale. Nu sunt
aplicaii necesare pentru acest clasa de rspuns/status. Aceste status-uri pot fi ignorate.
100 - continu:
Utilizatorul ar trebui s i continuie cererea/aciunea. Acest rspuns provizoriu este folosit
pentru a informa utilizatorul ca partea iniial a cereri a fost receptat i c deocamdat nu a fost
refuzat de server. Utilizatorul ar trebui s continuie i s ignore acest rspuns.
101 - schimbare protocol:
Server-ul nelege i are intenia de a de a ndeplini cererea utilizatorului, rspunnd prin aceast
eroare c pri ale server-ului sunt n proces de schimbare/mutare. Server-ul va schimba protocolul
imediat dup ce rspunsul pentru linia 101 va fi terminat. Protocolul ar trebui schimbat doar n
momentul n care acest lucru este avantajos i se permite.
-2xx - rspuns reuit: clasa de rspuns/status ce indic utilizatorului c cererea a fost
primit, neleas i acceptat cu succes.
200 - ok:
Aceast cerere a fost executat cu succes. Informaia a revenit cu un rspuns pozitiv, indiferent
de modul n care s-a fcut cererea.
201 - creat/realizat:
Cererea a fost ndeplinit avnd ca rezultat crearea unui nou rezultat. Noul rezultat poate fi
referit/raportat de ctre URI-uile napoiate la intrarea rspunsului.
202 - acceptat:

Cererea a fost acceptata pentru procesare, dar aceasta din urma nu a fost terminat complet.
Scopul acestui mesaj este de a permite unui server s accepte cereri de la ali utilizatori, fr a cere
conexiunii clientului s insiste pn ce procesul/cererea e complet.
203 - informaie neautorizat:
Informaia returnat/revenit nu e definitiv ca fiind din server-ul principal, ci e adunat
recepionat de la un server local.
204 - fr coninut:
Server-ul a ndeplinit cererea i nu e nevoit sa ntoarc rspunsul, dar ar dori s rspund printr-o
informaie recent, gen meta.
205 - coninut refcut:
Cererea a fost ndeplinit i ar trebui ca browser-ul s poat modifica/reseta modul de vizualizare
a documentului ce a cauzat aceast cerere ctre server.
206 - coninut parial:
Serverul a ndeplinit parial cererea de primire de la surs.
-3xx - redirectri: aceast clas de rspuns/status indic faptul c aciunile urmtoare vor
trebui fcute de browser pentru a putea fi ndeplinit cererea. Cererea ar putea fi direcionat
de browser fr a interaciona cu utilizatorul dac i numai dac metoda folosit n cea de a
doua cerere este Primit/recepionat sau Direcionat/condus.
300 - diferite/multiple alegeri:
Sursa cererii corespunde unor seturi de descrieri, fiecare cu locaii specifice, iar browser-ul dat fiind
negocierea informaiei, primete rspunsul astfel nct utilizatorul/browser-ul s poat alege modul
dorit astfel nct redirectarea s fie spre acea locaie. n cazul n care cererea a fost de tip
Condus/trimis, rspunsul ar trebui s includ o intrare cu lista caracteristicilor i locaiilor 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 urmtoare ar trebui s
foloseasc una din sursele returnate URI. Dac acest mesaj/cod este primit ca rspuns al unei cereri
tip Primit/recepionat sau Direcionat/condus, browser-ul nu trebuie s redirecioneze automat
cererea, doar dac nu poate fi confirmat de ctre utilizator.
302 - gsit:
Sursa cererii este temporar pe un alt URI. n cazul n care redirectarea 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 recepionat ca rspuns al unei cereri alta dect
Primit/recepionat sau Direcionat/condus, browser-ul nu trebuie s redirecteze automat cererea
dac aceasta nu poate fi confirmat de ctre utilizator.
303 - vezi alta surs:
Rspunsul cererii poate fi gsit sub un diferit URI i ar trebui s fie recepionat folosind metoda
Primit/recepionat de la acea surs.
304 - nemodificat:
n cazul n care clientul a efectuat o cerere de tip Primit/recepionat i accesul este permis, dar
documentul nu a fost modificat, serverul ar trebui s rspund cu acest mesaj/status.
305 - folosete proxy:
Cererea trebuie accesat printr-un proxy dat de ctre cmpul de locaie. Acesta este dat de ctre
URI. Beneficiarul va repeta acest unic cerere prin intermediul unui proxy. Rspunsul 305 va fi
generat doar de ctre serverul de origine.
306 (nefolosit):
Acest mesaj/status a fost folosit ntr-o vesiune anterioar a specificaiilor deci nu mai este folosit,
el fiind reinut.
307 - redirectare temporar:
Sursa cerut se afl temporar la un diferit URI. Din moment ce redirectarea poate fi modificata
ocazional, utilizatorul ar trebui s continue s foloseasc URI-ul cerut pentru viitoarele aciuni.

-4xx - erori ale utilizatorilor: aceast clas de mesaje/statusuri este folosit n cazurile n
care utilizatorul ar putea grei formularea cererii. Excepia fiind rspunsurule pentru cererile
tip Direcionat/condus, atunci serverul ar trebui s conin o intrare cu o explicaie a
situaiei erorii i dac e o eroare temporar sau pemanent. Aceste rspunsuri sunt aplicabile
pentru orice fel de cerere. Browser-ele ar trebui s arate orice intrare cerut de utilizator.
400 - cerere greit:
Cererea nu a putut fi neleas/perceput de ctre server din cauza unei sintaxe
greite/incomplete. Utilizatorul ar trebui s nu repete cererea fr ca aceasta s suporte modificri.
401 - neautorizat:Cererea necesit autentificarea/nregistrarea utilizatorului. Rspunsul
trebuie s includ WWW - cmp de autentificare coninnd o somaie aplicabil utilizatorului.
Utilizatorul poate repeta cererea. Dac cererea deja includea cmpul de autorizare, atunci
rspunsul 401 indic faptul c autorizarea a fost refuzat. Dac rspunsul 401 conine aceeai
somaie ca rspuns principal iar browser-ul a executat autentificarea cel puin o dat, atunci
utilizatorul ar trebui s i se prezinte intrarea dat n rspuns, din moment ce aceasta include
informaii relevante.
402 - necesit plata:
Rezervat pentru utilizare ulterioar.
403 - interzis:
Serverul a neles cererea, dar refuz s o ndeplineasc. Autorizarea nu ajut n nici un caz, iar
cererea nu ar mai trebui repetata
404 - negsit:
Serverul nu a gsit nimic care s corespund cererii URI. Nu se dau indicaii despre condiia
temporar sau permanent.
405 - metod nepermis:
Metoda specificat n linia de cerere (Request-Line) nu este permis de ctre sursa identificat
dup URI-ul cerut.

406 - neacceptat:
Sursa identificat de cerere este capabil s genereze doar intrri care au coninut specific
neacceptat de ctre condiiile de acceptare trimise prin cerere.
407 - autentificare prin proxy:
Mesajul este similar celui 401, dar indic situaia n care utilizatorul trebuie s se autentifice prin
proxy.
408 - cerere expirat:
Utilizatorul nu a fcut cererea n timpul n care serverul era pregtit sa o atepte. Se poate repeta
cererea fr modificri prealabile.
-5xx - erori de server: rspunsurile/status-urile ce ncep cu unitatea/cifra 5 indic cazurile
n care serverul e contient de greelile produse sau e incapabil s execute cererea. Excepie
fcnd rspunsul unei cereri Direcionat/condus, serverul ar trebui, n acest caz s includ
o afiare cu o explicaie a situaiei de eroare, fie c e temporar sau permanent.
500 - eroare intern de server:
Server-ul a ntmpinat o condiie neateptat i o previne spre a putea ndeplini cererea.
501 - nendeplinit/nerecunoscut:
Server-ul nu poate suporta funcionalitatea cerut pentru a putea ndeplini cererea. Acesta este
rspunsul specific n cazurile n care server-ul nu recunoate metoda de cerere i nu e capabil s o
suporte indiferent de mijloc/resurs.
502 - poart/ieire greit:
Server-ul, n timp ce ncerca s se comporte ca o poart/ieire sau ca un proxy, a recepionat un
rspuns 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 suprancrcri sau a
serviciilor de ntreinere a server-ului ce au loc n acel moment. Aceasta este o stare temporar i n
curnd va fi remediat.
504 - poart/ieire expirat:
Server-ul, n timp ce ncerca s se comporte ca o poart/ieire sau ca un proxy, nu a primit un
rspuns 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 accesrii n ncercarea de a termina/ndeplini cererea.
505 - versiunea HTTP nu e suportat/susinut:
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
aceeai versiune cu cea a clientului.

1.5.VERSIUNI HTTP
1

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 mbuntiri;

HTTP/1.1 versiune de mbuntire 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 stabilete o nou conexiune TCP naintea cererii, iar dup transmiterea rspunsului
conexiunea trebuie nchis. Astfel dac un document HTML cuprinde 10 imagini, vor fi necesare 11
conexiuni TCP, pentru ca pagina s fie afiat complet (n browser). La versiunea 1.1 se pot emite
mai multe cereri i rspunsuri pe aceeai 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 ncrcare a paginii. La aceasta se adaug i faptul c versiunea 1.1
poate relua i continua transferuri ntrerupte.
La HTTP se pierd informaiile cererilor vechi (deci este un protocol fr reinerea strii). Prin
utilizarea de cooki-uri n header, se pot realiza ns aplicaii care pot utiliza informaii de stare

(opiunile utilizatorului din sesiunea actual, co de cumprturi .a.). Chiar i o recunoatere a

utilizatorului este astfel posibil. n mod normal se pot citi informaiile transmise care parcurg
reeaua 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 rennoiete complet coninutul ferestrei browser-ului. Noua versiune permite
pe lng 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 urmri calea spre
webserver, i verifica dac datele au fost corect transferate. Astfel se poate urmri calea prin diferite
proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicaie.

1.6 FORMATUL MESAJELOR DE CERERE

Linia de cerere a unui mesaj HTTP este definita astfel:
Request-Line ::= Method Separator Request-URI Separator HTTP-Version
CRLF
Method ::= "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" |
"TRACE"
Request-URI ::= "*" | absolute-URI | abs_path

1.7.DESCRIEREA METODELOR
Serverul va returna codul 405 (Method Not Allowed) sau 501 (Not Implemented) daca se
va trimite numele unei metode inexistente.
Descrierea metodelor permise urmeaza mai jos:
-OPTIONS

Reprezint o cerere de informaii despre opiunile de comunicare disponibile ntr-un dialog

cerere/raspuns.
-GET

Reprezint o cerere de accesare a unor informaii (entitati) identificate de Request-URI. Semantica

metodei GET se schimba n cerere conditionat dac mesajul de cerere include cmpuri antet IfModified-Since, If-Match, If-Range.

Daca se specifica un cmp Range, atunci GET va specifica

o cerere partial.
-HEAD

Este similar cu GET, dar serverul va returna un mesaj avnd informatii doar n antetul lui. Metainformatiile din antetele HTTP din rspunsul la o cerere HEAD vor fi identice cu cele din rspunsul
la o cerere GET. Metoda HEAD este folosit deseori pentru testarea validitaii, accesibilitaii si
modificrilor recente ale unei legaturi hipertext. Pentru documente HTML, o cerere HEAD va avea ca
rspuns doar antetul paginii, adic informaiile cuprinse ntre marcatorii <head>...</head>.

-POST

Metoda e utilizat s identifice dac serverul accept o entitate nglobat n cadrul cererii. POST
este proiectat s implementeze o metod uniform pentru functiile: adnotarea resurselor,
trimiterea unui mesaj ntr-o list de tiri, trimiterea datelor unui formular Web, extinderea unei baze
de date printr-o operaiune de adugare. Semantica exact a metodei este definit de server.
Rspunsul serverului poate fi 200 (OK), 201 (Created) sau 204 (No Content).
-PUT

Specific faptul c o entitate inclus n mesaj sa fie stocat la adresa dat de Request-URI. Dac
resursa deja exist, se consider o actualizare a ei. Diferena fundamental ntre PUT si POST este
reflectat de modul diferit de manipulare a adresei REquest-URI. ntr-o cerere POST, URI identifica
resursa care va prelucra entitatea nglobat de mesaj. Acea resurs poate fi un proces de prelucrare a
datelor, o poart ctre alt protocol, o entitate separat acceptnd adnotri. Prin contrast, URI dintrun PUT identific entitatea inclus n mesajul de cerere. O unica resursa poate fi identificat de URIuri multiple.
-DELETE

Cere ca serverul s tearg resursa identificat de Request-URI.

-TRACE

Invoc o cerere de diagnosticare (trasaj).

1.7.EXEMPLU DE HTTP
Cererea clientului:
GET / HTTP/1.1
Host: www.example.com
Rspunsul 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