"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 https:

Content-Location ::= "Content-Location" ":" http-URL http-URL ::= "https://" host a ":" port i a abs_path i

De exemplu: https://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:

https://www.infoiasi.ro:80/Ibusaco/poems.html https://www.infoiasi.ro/%7Ebusaco/poems.html https://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 intr-un dialog cerere/raspuns.

GET
Reprezinta o cerere de accesare a unor informatii (entitati) identificate de Request-URI. 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=https://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 e-mail, 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 (intr-un 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.Grönbaek, 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": https://www.psl.cs.columbia.edu/Rivendell/