Protocolul de transport al hiper-textelor:

HTTP
"Experienta este magistrul tuturor lucrurilor." (Caesar) g7z1zf
1. Introducere
Protocolul de transport al hiper-textelor HTTP (Hyper-Text Transport Protocol) este
un protocol bazat pe stiva de protocoale TCP/IP, destinat sistemelor hipermedia
conlucrind in medii distribuite. HTTP a inceput sa fie proiectat si utilizat din anul
1990, dezvoltindu-se impreuna cu spatiul WWW.
Prima versiune, referita ca HTTP/0.9, a reprezentat un simplu protocol de transfer
de date prin Internet. Urmatoarea versiune, HTTP/1.0, definita de RFC 1945, a
imbunatatit transferul de mesaje, permitindu-se mesaje in format MIME
(Multipurpose Internet Mail Extensions), continind meta-informatii despre datele
transmise si despre semantica dialogului cererilor si raspunsurilor dintre clientii si
serverele Web.
A urmat HTTP/1.1 care ofera mai multe functionalitati suplimentare, precum
mecanisme de cautare, adnotare si actualizare, avind suport pentru URI (Uniform
Resource Identifier), specificind adresele ca locatie (prin URL) sau prin nume (via
URN). HTTP de asemeni este utilizat ca protocol generic pentru comunicarea intre
agentii utilizator si portile (gateways) catre alte sisteme Internet, incluzind suport
pentru protocoale ca SMTP (Simple Mail Transfer Protocol), NNTP (Network
News Transfer Protocol), FTP (File Transfer Protocol), Gopher. In acest mod,
HTTP permite accesul hipermedia la resurse disponibile din diverse aplicatii.
Protocolul HTTP este un protocol sigur, de tip cerere/raspuns, comunicatiile
decurgind peste conexiunile TCP/IP, portul standard de acces fiind portul 80.
2. Terminologie
Vom folosi in cele ce urmeaza urmatorii termeni:
conexiune
Un circuit virtual la nivelul transport stabilit intre doua programe care doresc sa
comunice.
mesaj
Unitatea de baza a unei comunicatii HTTP, constind dintr-o secventa structurata de
octeti, transmisa printr-o conexiune.
cerere
Un mesaj de cerere HTTP (vezi mai jos).
raspuns
Un mesaj de raspuns HTTP.

resursa
Un obiect de date sau serviciu care poate fi identificat de un URI. Resursele pot
avea reprezentari multiple (e.g. formate, marimi, rezolutii etc.).
entitate
Informatia transferata intr-o operatie de cerere sau de raspuns. O entitate cuprinde
atit meta-informatii, cit si continutul propriu-zis.
reprezentare
O entitate inclusa intr-un raspuns ce reprezinta o negociere intre client si server.
negociere
Mecanism de selectare a reprezentarii potrivite a unei date solicitate.
client
Un program care stabileste conexiuni cu scopul de a trimite cereri.
agent-utilizator
Clientul ce initiaza o cerere (navigator, editor, robot de traversare Web).
Navigatoarele cele mai cunoscute sint Netscape Navigator, Internet Explorer,
Arena, Mozaic.
server
O aplicatie care accepta conexiuni, raspunzind la anumite cereri transmise de
clienti. Un program poate juca rol atit de server, cit si de client. Un server se poate
comporta ca server initial, poarta, tunel sau proxy Web in functie de natura cererii.
Cele mai cunoscute servere Web sint: Apache, Netscape Enterprise Server, Sun
Web Server, Windows NT Web Server, Stronghold.
proxy (intermediar)
Un program intermediar care ruleaza ca server, cit si drept client pentru a transmite
cereri altor servere. Cererile trimise unui proxy pot fi rezolvate intern sau transmise
mai departe, catre alte servere (posibil translatate). Un proxy trebuie sa
implementeze cerintele de server si de client ale specificatiei HTTP.
poarta
Un server care lucreaza ca intermediar pentru alte servere, in mod transparent, fiind
si un translator de protocoale.
tunel
Un program intermediar functionind ca mijlocitor intre doua conexiuni.
cache
Un depozit local de memorare a mesajelor (datelor) de raspuns si un subsistem de
control al acestuia. Memoria cache reduce timpul de raspuns si congestia retelei.
Orice client si server poate include un cache.
In figura urmatoare vom ilustra structura unui server Web sub Linux:

Figura 1. Structura platformei Web in Linux

3. Mesaje HTTP
Un mesaj HTTP este divizat intr-o parte de antet si o parte corp. Antetul cuprinde o
serie de cimpuri (unele dintre ele obligatorii) oferind informatii despre versiunea de
protocol folosit, codificarea datelor, tipul de medii, lungimea si tipul mesajului etc.
Sintaxa unui antet de mesaj este:
message-header ::= field-name ":" a field-value i CRLF
Formatul unei cereri este urmatorul:
Request ::= Method Request-URI ProtocolVersion CRLF
a message-header i a CRLF data i
Method ::= string data ::= MIME-data
Raspunsul la o cerere are urmatoarea sintaxa:
status-line ::= HTTP-version status-code reason CRLF status-code ::= digit digit
digit reason ::= string
3.1 Structura
Orice mesaj HTTP trebuie sa debuteze cu un cimp indicind versiunea protocolului
in prima linie a mesajului:
HTTP-Version ::= "HTTP-Version" ":" "HTTP" "/" digit "." digit
In prezent este operational protocolul 1.1 deci toate mesajele de cerere si de raspuns
vor incepe cu linia HTTP/1.1.
Mesajele pot fi codificate conform autoritatii IANA (Internet Assigned Numbers
Authority) fiind permise codificarile:
gzip (GNU zip) este un cod Lempel-Ziv (LZ77) cu suma de control pe 32 de biti
compress este un cod produs de programul compress din toate mediile UNIX, dupa
codificarea Lempel-Ziv-Welch (LZW)
Aceste codificari sint specificate de cimpul Content-Transfer-Encoding.
Pentru MIME, se specifica tipul si subtipul mediului de informatii (de exemplu:
text/html, text/plain, image/jpeg, video/mpeg etc.) in cimpul Content-Type. Un
mesaj poate fi tranmis in format multipart, constind din mai multe entitati, toate
avind o sintaxa comuna. Daca o aplicatie receptioneaza un subtip nerecunoscut, in
mod automat il va trata ca multipart/mixed.
Cimpul Accept dintr-un mesaj de cerere poate specifica multimea de tipuri de date
returnata de server ca raspuns:
Accept ::= "Accept" ":" (media-range a accept-params i)+ media-range ::= ("*/*" |
type "/*" | type "/" subtype)* accept-params ::= ";" "q=" qvalue accept-extension*

accept-extension ::= ";" token a "=" (token | string) i type ::= string subtype ::=
string qvalue ::= digit "." digit
Simbolul "*" specifica toate tipurile/subtipurile de medii dintr-o anumita categorie.
De exemplu, pentru a accepta doar imagini, indiferent de format, se va transmite
Accept: image/*.
Pot fi specificati unul sau mai multi factori de calitate relativa. De pilda, cererea
Accept: audio/*; q=0.2, audio/basic este interpretata astfel: "se prefera tipul
audio/basic dar serverul va trebui sa trimita toate tipurile audio avind calitatea de
cel putin 80%".
Locatia unei resurse HTTP va fi data de cimpul Content-Location in formatul URI,
conform schemei http:
Content-Location ::= "Content-Location" ":" http-URL http-URL ::= "http://" host a
":" port i a abs_path i
De exemplu: http://www.infoiasi.ro/Ibusaco/egon/http.html
Daca portul nu apare, se ia prin definitie portul 80, rezervat protocolului HTTP.
Adresele host vor fi tratate indiferent de scrierea cu caractere majuscule sau nu
(case-insensitive), dar calea de directoare abs_path este tratata case-sensitive
(majusculele sint diferite de minuscule). Daca abs_path nu apare, se va considera
"/", iar caracterele rezervate vor fi echivalente cu codul lor in hexa, precedat de "%"
(in forma "% hex hex").
De exemplu, aceste trei URI sin echivalente:
http://www.infoiasi.ro:80/Ibusaco/poems.html http://www.infoiasi.ro/
%7Ebusaco/poems.html http://WWW.InfoIasi.Ro/%7ebusaco/poems.html
Corpul mesajului va contine informatiile propriu-zise ale unei cereri sau raspuns,
specificate de o entitate. O entitate-corp difera de corpul mesajului numai daca sint
aplicate codificari.
3.2 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
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
Reprezinta o cerere de informatii despre optiunile de comunicare disponibile intrun dialog cerere/raspuns.
GET
Reprezinta o cerere de accesare a unor informatii (entitati) identificate de RequestURI. Semantica metodei GET se schimba in cerere conditionata daca mesajul de
cerere include cimpuri antet If-Modified-Since, If-Match, If-Range etc. Daca se
specifica un cimp Range, atunci GET va specifica o cerere partiala.
HEAD
Este similara cu GET, dar serverul va returna un mesaj avind informatii doar in
antetul lui. Meta-informatiile din antetele HTTP din raspunsul la o cerere HEAD
vor fi identice cu cele din raspunsul la o cerere GET. Metoda HEAD este folosita
deseori pentru testarea validitatii, accesibilitatii si modificarilor recente ale unei
legaturi hipertext. Pentru documente HTML, o cerere HEAD va avea ca raspuns
doar antetul paginii, adica informatiile cuprinse intre marcatorii <head>...</head>.
POST
Metoda e utilizata sa identifice daca serverul accepta o entitate inglobata in cadrul
cererii. POST este proiectata sa implementeze o metoda uniforma pentru functiile:
adnotarea resurselor, trimiterea unui mesaj intr-o lista de stiri, trimiterea datelor
unui formular Web, extinderea unei baze de date printr-o operatiune de adaugare.
Semantica exacta a metodei este definita de server. Raspunsul serverului poate fi
200 (OK), 201 (Created) sau 204 (No Content).
PUT
Specifica faptul ca o entitate inclusa in mesaj sa fie stocata la adresa data de
Request-URI. Daca resursa deja exista, se considera o actualizare a ei. Diferenta
fundamentala intre PUT si POST este reflectata de modul diferit de manipulare a
adresei REquest-URI. Intr-o cerere POST, URI identifica resursa care va prelucra
entitatea inglobata de mesaj. Acea resursa poate fi un proces de prelucrare a datelor,
o poarta catre alt protocol, o entitate separata acceptind adnotari. Prin contrast, URI
dintr-un PUT identifica entitatea inclusa in mesajul de cerere. O unica resursa poate
fi identificata de URI-uri multiple.
DELETE
Cere ca serverul sa stearga resursa identificata de Request-URI.
TRACE
Invoca o cerere de diagnosticare (trasaj).
3.3 Coduri de stare
Pentru fiecare cerere a unui client, serverul HTTP raspunde cu o serie de coduri de
stare a operatiei solicitate, dintre care mentionam:
Coduri de informare (1xx)
Acestea dau informatii despre o anumita actiune:

100 Continue - clientul poate continua cererea, trebuind sa trimita urmatoarea parte
a unui mesaj partial;
101 Switching Protocols - serverul intelege cererea, dar necesita receptionarea unui
cimp Upgrade pentru a sti ce tip de protocol va fi folosit la nivelul aplicatiei (e.g.
pentru transmiterea de informatii multimedia, cind poate fi utilizat un protocol
sincron, in timp-real);
Coduri de succes (2xx)
Acestea raporteaza efectuarea cu succes a unui operatiuni:
200 Ok - cererea a fost rezolvata cu succes;
201 Created - o noua resursa a fost creata cu succes. Resursa creata poate fi
identificata de URI-ul returnat de entitatea-raspuns, trebuind a fi generata inainte de
returnarea codului (in caz contrar se trimite 202);
202 Accepted - cererea a fost acceptata spre procesare, dar inca n-a fost satisfacuta
in intregime. Nu exista nici o facilitate pentru retransmiterea unui cod de stare in
urma executiei unei operatii asincrone;
204 No Content - serverul a rezolvat cererea, dar nu are ce returna;
Coduri de redirectare (3xx)
Indica o redirectare, catre alta locatie/server a cererii (de exemplu, la aparitia
marcatorului <meta name="refresh" content="..."> in cadrul unui document
HTML):
300 Multiple Choices - resursa ceruta corespunde uneia dintre reprezentarile
multiple pe care le are;
301 Moved Permanently - resursa ceruta a fost asignata unui URI nou si orice
referinta viitoare la ea trebuie sa se realizeze prin acest URI returnat;
302 Moved Temporarily - resursa ceruta are un alt URI, pentru o perioada
temporara;
303 See Other - raspunsul la cerere poate fi gasit la o alta locatie URI si trebuie
accesat folosind o metoda GET;
305 Use Proxy - resursa ceruta trebuie accesata printr-un proxy desemnat de cimpul
Location;
Coduri de eroare client (4xx)
Indica aparitia unei erori pe partea clientului:
400 Bad Request - cererea n-a putut fi inteleasa de server din cauza unei sintaxe
eronate a metodei;

401 Unauthorized - cererea necesita autentificarea utilizatorilor, prin transmiterea

unui cimp Authorization;
403 Forbidden - serverul intelege cererea, dar refuza s-o satisfaca din diverse
metode;
404 Not found - serverul nu gaseste resursa specificata de Request-URI;
406 Not Acceptable - resursa este incompatibila cu antetul cererii;
Coduri de eroare server (5xx)
Sint coduri semnificind o eroare pe partea serverului:
501 Not Implemented - serverul nu are implementata o functionalitate necesara
satisfacerii unei cereri;
502 Bad Gateway - serverul, lucrind ca poarta sau proxy, a receptionat un raspuns
invalid de la alt server caruia i-a trimis cererea;
503 Service Unavailable - serverul nu poate satisface cererea, din cauza
supraincarcarii temporare sau a unor ratiuni de administrare;
504 Gateway Timeout - timpul de asteptare a raspunsului a expirat.
Pot fi transmise si coduri de avertisment, cu valori cuprinse intre 0 si 99.
Exemplu
Urmeaza un exemplu de cerere HTTP pentru accesarea unui document HTML.
Liniile subliniate reprezinta cererea din partea unui client, urmata de replica
serverului Web:
GET / HTTP/1.1
Host: www.infoiasi.ro
HTTP/1.1 200 OK
Date: Thu, 23 Sep 1999 07:18:22 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
Last-Modified: Fri, 28 Aug 1998 07:03:53 GMT
ETag: "35028-181-35e65659"
Accept-Ranges: bytes
Content-Length: 385
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Final//EN">
<HTML>
<HEAD>
<META http-equiv="refresh" content="0; url=http://www.infoiasi.ro/Ibusaco/fcs">
<TITLE>Faculty of Computer Science</TITLE>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000"

LINK="#0000FF" VLINK="#000080" ALINK="#FF0000">
...
Securitate
Protocolul HTTP fiind bazat pe TCP/IP nu ofera suport pentru securitatea datelor,
acest lucru fiind rezolvat, la nivel protocol, prin doua metode:
SSL (Secure Socket Layer) este un sistem proiectat de Netscape care ofera o cale
TCP/IP criptata intre doua masini, suportind protocoalele HTTP, TELNET sau FTP.
SSL foloseste o varietate de sisteme de criptare pe chei publice si secrete.
Implementarea HTTP pentru SSL se numeste HTTPS.
SHTTP (Secure HTTP) este un sistem de criptare pentru HTTP conceput de
CommerceNet, oferind mecanisme de securitate prin semnatura, autentificare si
cifrare, folosite independent sau impreuna.
4. Un protocol pentru interactiunea sistemelor hipermedia deschise: OHP
Alternativa la HTTP, protocolul OHP (Open Hypermedia Protocol) intentioneaza a
sustine interconectarea sistemelor hipermedia deschise, oferind o serie de
functionalitati intr-o maniera independenta de hardware, mai ales pe partea client:
invocarea proceselor (lansarea aplicatiilor client pentru utilizatori), modelarea
mediului-utilizator (prin adoptarea conceptului de niveluri de protocol), translarea
(conversia) protocoalelor, standardizarea serviciilor-client, suport pentru proxy la
nivelul clientului.
Invocarea proceselor se poate implementa prin intermediul unui servlet Java care
poate rula pe orice platforma, acceptind cereri pentru lansarea aplicatiilor via
mesajelor HTTP. Invocarea unei aplicatii respecta un asa-numit scenariu. De
exemplu, un utilizator poate folosi un program favorit de vizualizare a hipertextelor
apelat ca raspuns la un scenariu "vizualizeaza". Ca exemplu de sistem folosind
aceasta tehnica putem da Rivendell, dezvoltat la Universitatea Columbia.
Modelarea mediului de operare al utilizatorilor poate fi rezolvata prin proiectarea
unui interfete de programare utilizind tehnologia orientata pe componente, ca
JavaBeans.
Protocolul OHP se structureaza pe diverse niveluri:
nivelul 0 ofera functionalitatea de baza, primara, a protocolului, specificind modul
de deschidere a unui nod hipertext (LaunchDocument) si de inchidere a acestuia
(CloseNode). Orice alte mesaje vor avea semantici descrise de nivelurile
superioare.
nivelul 1 ofera mijloacele de manipulare a continutului documentelor hipermedia.
nivelul 2 si cele superioare inca nu au fost definite de specificatiile OHP, fiind
destinate unor dezvoltari ulterioare.

Principalul scop urmarit in proiectarea protocolului a fost acela de a permite

construirea unui set deschis, extensibil, de interfete care sa ofere acces la o varietate
de servicii hipermedia. Fiecare tip de medii de date poate folosi protocoale
specifice, de aceea trebuie avuta in vedere conversia mesajelor OHP in mesaje
respectind alte protocoale. Astfel se asigura integrarea aplicatiilor.
Standardizarea serviciilor-client se poate rezolva prin implementarea de
componente JavaBeans permitind dezvoltarea unui mecanism de comunicare intre
sistemele hipermedia deschise, prin TCP/IP ca mijloc de transport si XML ca
format al mesajelor.
Cerintele de proiectare a unei arhitecturi deschise sint urmatoarele:
Integrarea - sistemele hipermedia trebuie sa integreze serviciile existente, ca
programe, agenti software, aplicatii suplimentare (editoare, navigatoare, sisteme email, programe de calcul tabelar) si depozite de date (hiperbaze de date, servere de
legatura, sisteme de administrare a documentelor, sisteme de fisiere si CD-ROM si
altele).
Hipermedia - trebuie suportata o varietate larga de servicii hipermedia (ancore,
legaturi, noduri continut, specificatori, referinte incrucisate etc.).
Distribuire - sistemele trebuie sa ruleze pe diferite configuratii hardware si
software, in cadrul retelelor locale si in domenii Internet.
Colaborare - sistemele deschise trebuie sa asigure suport pentru proiectarea si
exploatarea colaborativa a continutului si structurii documentelor hipermedia (intrun mod asincron si sincron).
In plus, sistemele hipermedia deschise vor trebui sa aiba o arhitectura conceptuala,
generala, simpla si adaptabila. De aceea, in cadrul proiectarii protocolului OHP au
fost avute in vedere, ca surse de inspiratie, modele hipertext precum Flag, Dexter,
Shim si HyperDisco.
OHP trebuie sa conlucreze cu alte protocoale deschise: DBP (Hypermedia
DataBase Protocol), DMP (Document Management Protocol), AP (Agent Protocol).

5. Referinte bibliografice
K.Anderson - "Client-Side Services for Open Hypermedia", Open Hypermedia
Systems Workshop, Irvine, 1998
V.Balasubramanian - "State of the Art Review on Hypermedia Issues And
Applications", Rutgers University, New Jersey, 1994
T.Berners-Lee - "Hypertext Transfer Protocol - HTTP/0.9", Internet Draft, CERN,

nov.1993
W.Duane - "Intelligent Caching for WWW Objects", WWW Conference, may
1995
R.Fielding (ed.) - "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, IETF,
1997
L.Floridi - "Internet: Frankestein Or Pygmalion?", Oxford Press, 1995
N.Georganas - "Self-Similar ('Fractal') Traffic in ATM Networks", Multimedia
Communications Research Laboratory, Ottawa, 1995
V.Groza, D.Ionescu, N.Georganas - "An Architecture for Multimedia over ATM
Real-Time Environments", University of Ottawa, 1996
K.Grnbaek, U.K.Wiil - "Towards a Reference Architecture for Open
Hypermedia", Hypertext'97 Proceedings, ACM Press, 1997
V.V.Patriciu et al. - "Securitatea informatica in UNIX si Internet", Ed.Tehnica,
Bucuresti, 1998
A.Preoteasa - "Servere Web", PC Report, vol.7/10, nr.73, oct.1998
A.Tanenbaum - "Retele de calculatoare", Computer Press Agora, Tg.Mures, 1996
D.Todoroi et al. - "Transition to a Full Information Society: Stage Development",
Working Paper no.98-2, UNO, Omaha, 1998
A.Vanzyl et al. - "Open Hypertext Systems", Monash University, Australia, 1995
* * * - "The Rivendell Tool Server": http://www.psl.cs.columbia.edu/Rivendell/