Capitolul 1.

INTERNET i World Wide Web

1.1. Introducere Ce este Internetul?
Internetul a fost descris ca o colecie larg de reele sau ca o reea de reele. Dei ambele definiii snt corecte, nici una nu surprinde Internetul n totalitatea sa. Pe lng instrumentul care este aceast imens conexiune, Internetul nseamn i mulimea comunitilor celor ce l folosesc, fiecare n scopuri diferite: comunitatea academic utilizeaz Internetul ca pe cel mai mare, complet i totodat complex instrument de nvare (educaional); comunitatea tiinific utilizeaz Internetul ca pe un instrument de cercetare i colaborare; comunitatea economic utilizeaz Internetul ca pe un mediu de derulare al afacerilor.

Internetul nu este o organizaie monolitic, avnd o conducere i un grup de control unice; Internetul este o societate de reele de calculatoare interconectate, independente dar care (din anumite motive) se supun unor protocoale globale.

Ce este World Wide Web (WWW, W3)

World Wide Web (WWW sau W3) este o reea de resurse informaionale de o extraordinar de mare diversitate n ceea ce privete coninutul. Este un sistem interactiv hipermedia (adic un sistem ce conine i suport patru categorii importante de tipuri de informaie: texte, imagini, sunete/audio i imagini video n micare) construit peste Internet. Pentru a face aceste resurse disponibile (utilizabile) unei audiene ct mai largi, Web-ul se sprijin pe 3 mecanisme fundamentale: 1. 2. 3. O schem uniform de denumire (de stabilire a numelor, naming scheme) pentru a localiza resursele n Web (de exemplu URI). Protocoale pentru accesarea resurselor astfel denumite n Web (de exemplu HTTP) Hypertextul pentru navigarea comod de la o resurs la alta (ntre resurse).

Elementele fundamentale ale WWW snt prezentate n figura urmtoare:

World Wide Web este cel mai vizibil instrument Internet, transformndu-l (prin capacitile sale de a prezenta informaiile) n cel mai important instrument al zilelor noastre i ntr-o surs de informaii fr egal. Web-ul poate fi utilizat pentru cutarea de informaii despre produse, transferul de software i versiuni noi ale acestuia, pstrarea unor colecii de informaii de orice fel de tip (de exemplu de ziare), n general pentru aflarea unor informaii despre orice tip de informaie imaginabil.

1.2. Resursele World Wide Web

Unul din conceptele de baz - preluat i acceptat i n alte protocoale utilizate n Internet este cel de resurs. O resurs poate fi un program, un calculator, un document, o baz de date, un serviciu - nu prea are importan, att timp ct poate fi referit n mod corect i fr echivoc. Pentru referirea la o resurs din Internet, se folosete termenul generic URI (Universal Resource Identifier) care poate specifica fie o locaie, caz n care se vorbete de un URL (Universal Resource Locator) fie un nume, caz n care se vorbete de un URN (Universal Resource Name). Unei resurse i se aplic o metod - iar pentru a specifica ce metod se dorete, ce date sau parametrii suplimentari o completeaz pe aceasta, se face uz de mesaje. Paradigma pe care se bazeaz protocolul este cea de cerere/rspuns. Cererea este emis de un client; acesta stabilete o conexiune cu un server i i trimite acestuia o cerere, sub forma unei metode. Metoda se refer la o anumit resurs, identificat via URI; mai trebuie adugate versiunea de protocol utilizat i un mesaj de tip MIME care s conin parametrii metodei, informaii relative la client i un eventual coninut suplimentar. Serverul v rspunde cu o linie de stare, incluznd versiunea de protocol utilizat i un cod de succes sau eroare, la care se adaug un mesaj de tip MIME coninnd informaii relative la server i eventual un coninut suplimentar. Acest posibil coninut suplimentar este de regul o entitate - o reprezentare particular a unor date necesare n cerere sau n rspuns, i este structurat ntr-un antet (header) coninnd metainformaii relative la date (o descriere a felului n care trebuie citite datele) i datele propriu-zise, care formeaz corpul entitii.

1.3. Adresarea unei resurse n Web

Adresarea unei resurse via http se face prin construcii (iruri de caractere) de forma

http://adresa_host_in_retea[:port]/cale/subcalel/.../subcalen/nume_docu ment
http: specific tipul protocolului; el trebuie precizat dat fiind faptul c http nu este singurul protocol prin care poate fi accesat o anumit resurs din Internet. adresa_host_in_retea (de exemplu www.xxx.ro sau www.stpt.com) identific un server sau un gateway din reea, folosind adresarea uzual de tip DNS (Domain Name Service) din Internet:

numehost.subdomeniul.subdomeniu2..subdomeniun.domeniu_de_baz
Deci www.xxx.ro s-ar citi serverul www din subdomeniul xxx din domeniul de baz ro. :port poate lipsi, ceea ce nseamn c se presupune implicit c se face referin la portul standard, 80. Dac se specific un alt port, se va adresa acesta. Cale/subcalel/.../subcalen/nume_document identific calea absolut pn la documentul identificat de nume_document de pe serverul respectiv. Nu ntotdeauna ns resursa 3

referit este un document! Poate fi o fraciune dintr-un document, caz n care se face referire la fragmentul respectiv: Cale/subcalel/.../subcalen/nume_document#capitolul2paragraful3 Sau, mai general, poate fi un program cruia trebuie s i se paseze civa parametri i o anumit cerere: Cale/subcalel/.../subcalen/nume_program;paraml;param2;...;paramn?cerere Exemplu: Urmtoarea referin http://guaraldi.cs.colostate.edu:2000/cgi-bin/savvyfrontend?KW=cuvnt_cheie & classic=on & tl=x & Boolean=AND & Hits=10 & Mode=MakePlan & df=normal & AutoStep=on. se va citi http://guaraldi.cs.colostate.edu:2000 ne spune c se va face o conexiune via http cu serverul guaraldi.cs.colostate.edu, utiliznd portul 2000 al acestuia. Pe acest server se va adresa programul savvy-frontend din directorul cgi-bin/, cruia nu i se paseaz ali parametri dect cei inclui n felul n care a fost formulat cererea: KW=cuvnt_cheie & classic=on & tl=x & Boolean=AND & Hits=10 & Mode=MakePlan & df=normal &A utoStep=on. Specificarea unei resurse nu trebuie s fie totdeauna absolut, ca n exemplul dat. Dac ne-am plasat deja ntr-un subdirector oarecare al unui server, se pot folosi adrese relative, care omit calea pn n acel director: subcalel/subcale2/.../subcalem/nume_resursa sau chiar pur i simplu nume resurs, dac resursa se afl n acelai director. n HTML adresarea URI se folosete pentru: crearea unei legturi spre un alt document sau spre o alt resurs (a se vedea elementele A i LINK) crearea unei legturi spre un stil de pagin (style-sheet) extern sau spre un script aflat ntr-un fiier surs extern (a se vedea elementele LINK i SCRIPT) Includerea ntr-o pagin a unei imagini, a unui obiect sau a unui applet (a se vedea elementele IMG, OBJECT, APPLET i INPUT). crearea unei imagini senzitive (a se vedea elementele MAP i AREA). transmiterea unui formular interactiv (a se vedea elementul FORM). crearea unui document cu frame-uri (a se vedea elementele FRAME i IFRAME). citarea unei referine externe (a se vedea elementele Q, BLOCKQUOTE, INS i DEL). referirea unor conveii de metadate care descriu un document (a se vedea elementul HEAD).

1.4. Elementele conexiunilor n spaiul WWW

n cazul cel mai simplu, legtura dintre client i server se realizeaz prin intermediul unei singure conexiuni. De foarte multe ori ns, este posibil s existe mai muli intermediari n conexiune. Acetia pot fi de trei feluri: proxy, gateway sau tunnel. Un proxy este un intermediar sofisticat: el primete cererile adresate unei resurse identificate printr-un URI, rescrie anumite pri ale mesajului sau chiar tot mesajul, dup care va transmite mesajul modificat ctre serverul adresat iniial. Cu aceast ocazie el se i substituie clientului iniial: rspunsul i va veni tot lui, iar proxy-ul va face probabil o rescriere a mesajului de rspuns ctre client. Dinspre server, nu se mai vede cine este clientul adevrat: toi clienii ce trec prin proxy snt ascuni, serverul primind numai cereri de la proxy. Acesta poate face n plus, ntr-un singur loc, o serie de verificri, relative la autentificare, securizare etc., care ar fi greu de implementat pe multe i diverse maini - toate calculatoarele client care trec prin acel proxy. Un proxy reprezint nspre restul lumii un grup de clieni, putndu-i trata pe acetia difereniat. Un gateway este similar unui proxy, dar pe partea de server. Este un receptor, un fel de camer de primire pus n faa unui server sau a unui grup de servere. Serverele de dup gateway nu se vd n restul lumii - ele snt, toate, reprezentate de gateway. Cererile sosite la gateway snt dirijate ctre serverele corespunztoare cererii (sau ctre serverul cel mai liber, de exemplu, dac faptul c exist mai multe servere vine din dorina de a disponibiliza mai mult putere de calcul). De regul are loc i o conversie de protocol, nspre protocolul pe care l cunoate sau l folosete un anumit server, care nu mai este obligat n felul acesta s cunoasc http. Un tunel este un intermediar neinteligent: el transport date pe care nu le nelege sau interpreteaz n nici un fel ntre dou conexiuni. Nu are loc nici un fel de schimbare a mesajelor, dect temporar, trecnd printr-o form intermediar, ntre intrarea n i ieirea din tunel; coninutul mesajelor nu se schimb. n cazul unei conexiuni mai complexe, o situaie comun ar putea fi cea din figura urmtoare:

O cerere sau un rspuns care parcurge drumul din figur va traversa patru conexiuni. Acest lucru trebuie avut n vedere; exist unele opiuni relative la comunicaie care se refer numai la primul vecin, dac acesta nu se afl n spatele unui tunel, altele care se refer numai la punctele finale ale conexiunii iar altele care se pot referi la toate conexiunile de pe traseu. Iar dac diagrama simplificat de mai sus este linear, nu trebuie uitat faptul c fiecare participant poate fi angajat simultan n comunicaii multiple. Proxy-ul din figur poate lucra deodat cu muli clieni, care se adreseaz la mai multe servere i care pot fi gsii prin conexiuni diferite. Oricare dintre participanii la conexiune cu excepia tunelului poate face uz de un cache intern care s scurteze drumul unui ciclu cerere/rspuns. Exemplul anterior ilustreaz i drumul unei cereri care s-a mai fcut o dat de ctre client, dar se afl nc n cache-ul proxy-ului: Desigur, nu toate rspunsurile se preteaz la a fi pstrate un timp n cache (pe ideea c poate mai cere cineva acelai lucru); pe de alt parte, cererile de la clieni pot formula anumite opiuni specifice relative la cache (nu accept dect rspunsuri de la server direct, nu accept rspunsuri memorate mai mult de x minute, etc.)

1.5. Protocolul HTTP 1.5.1. Introducere general

Este un protocol la nivel aplicaie destinat sistemelor de informare distribuite, colaborative, de genul hypermedia. Aprut ca protocol de baz pentru WWW nc din 1990, a cunoscut o serie de transformri, o versiune final neexistnd nici n prezent. Versiunea cea mai folosit este nc 1.0, iar versiunea 1.1 - compatibil n jos cu 1.0, dar aducnd mbuntiri n special n direcia folosirii mai eficiente a resurselor - este pe cale s se impun ca nou standard. De aceea, o parte din aspectele care urmeaz nu trebuie privite ca referine btute n cuie, ci ca instantanee ale unei specificaii pe cale s se nasc, extrase dintr-o schi, un draft care poate se va mai schimba mult. Numele este acronimul pentru HyperText Transfer Protocol, dei la origine hypertext a fost definitoriu, practica curent l-a dus destul de repede nspre hypermedia documentele vehiculate cuprinznd nu numai text, ci i sunet, imagine sau informaii structurate. Aplicaiile care folosesc protocolul - cei doi parteneri n discuie, cele dou capete ale unei conexiuni - snt entiti abstracte din punct de vedere al protocolului. Ele trebuie doar s poat comunica ntre ele ceea ce nseamn, n principiu, posibilitatea de a primi sau formula cereri i de a formula sau recepiona rspunsuri, ca n celebrul exemplu al filozofilor ce vorbesc dou limbi diferite, folosind pentru comunicare translatorii care trimit mesajele filozofilor (traduse) prin intermediul potailor. Nici un nivel nu se preocup de cellalt.

FILOZOFII TRANSLATORII POTAII

Cererile formulate n protocolul HTTP se refer la informaii care se pot afla stocate n diverse baze de date, n diverse formate, pe diverse calculatoare. Cum anume se traduc n cereri concrete date diferite, este o problem care depete protocolul: sarcina lui este doar s fixeze regulile care trebuie respectate de cele dou aplicaii participante la un moment dat n comunicare pentru ca s se poat nelege fr nici un fel de risc de interpretare eronat a unei cereri sau a unui rspuns.

1.5.2. Mesajele protocolului HHTP

Atunci cnd se transfer ceva utiliznd WWW se specific o resurs: serverul cruia am vrea s-i adresm cererea, ce conine aceasta, cu ce protocol lucrm. Pentru ca aceast cerere s ajung la server trebuie s trimitem un mesaj care s conin i resursa specificat mai sus. Mesajul va conine un i r de caractere de forma: GET specificare_resurs HTTP/1.1 CRLF versiune_protocol CRLF Forma general a unui mesaj de cerere este conform schemei de mai sus: Metod resurs Versiunea de protocol trebuie specificat deoarece nu toate serverele au implementat ultima versiune sau nu toi clienii o cunosc. Deci, pentru ca totui un server detept s se poat nelege i cu un client mai puin dotat, sau invers, i fr a renuna la posibilitile introduse de versiunile (mereu mai) noi ale protocolului, trebuie s se realizeze mai nti o negociere ntre server i client, relativ la ce tie fiecare i abia apoi s se desfoare transferul propriu-zis de date.

1.5.3. Metodele protocolului HHTP

Metodele snt de fapt operaiile care pot fi aplicate obiectelor constituite de resursele din reea, n accepiunea protocolului HTTP. Metoda va trebui s fie totdeauna primul 7

element dintr-o linie de cerere. Metodele prevzute n versiunea 1.1 snt urmtoarele: OPTIONS, GET, HEAO, POST, PUT, PATCH, COPY, MOVE, DELETE, LINK, UNLINK, TRACE, WRAPPED. OPTIONS semnific o cerere relativ la informaiile ce definesc opiunile de comunicare disponibile pe conexiunea ctre URI-ul specificat n cerere. Metoda permite determinarea opiunilor i/sau posibilitilor unui server, fr s determine o aciune din partea resursei adresate. i metoda are nevoie de parametri, nu numai resursa, iar n HTTP termenul consacrat pentru parametrii metodelor este header field sau antet de cmp. Definite n cadrul protocolului pentru fiecare metod, antetele de cmp pot avea valori care la rndul lor snt definite (dar nu limitate, extensiile fiind n principiu totdeauna posibile). Exemplu: O cerere de tipul OPTIONS www.xxx.ro HTTP1/1 CRLF Accept: audio/*; q=0.2, audio/basic CRLF reprezint o cerere de definire a opiunilor ctre serverul www.xxx.ro, n care clientul solicitant spune c prefer audio/basic, dar accept orice tip pentru date audio n cazul n care calitatea reprezentrii nu scade sub 20%. Exemplu: Iar o cerere de genul OPTIONS www.xxx.ro HTTP1/1 CRLF Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8; mxb=100000, text/xc CRLF specific urmtoarele preferine relative la modul de reprezentare al textului: x-c sau html, dac snt disponibile; dac nu, x-dvi, dar numai dac textul nu depete 100000 de octei, sau plain altfel. Virgula separ opiuni posibile, punct-virgul separ determinrile sau preferinele suplimentare relative la o anumit opiune. GET este una dintre cele mai importante metode i singura care era disponibil n prima versiune a protocolului, HTTP/0.9. GET este metoda care aduce ceva de la resurs; mai concret, dac resursa este un proces care produce date (o cutare de pild), rspunsul la metoda GET va fi o entitate care s cuprind acele date. Rspunsul este unul singur: aceasta este o caracteristic de baz a protocolului. Chiar dac volumul de date care trebuie incluse n rspuns este mare, nu se face o fracionare n bucele mai mici, care s permit transferul mai uor al rspunsului. Din punct de vedere al protocolului HTTP, discuia este totdeauna simpl: o ntrebare are un rspuns. Nu se pot pune mai multe ntrebri pentru a obine un singur rspuns, nu se pot formula mai multe rspunsuri la o ntrebare. Exist totui dou posibiliti de a micora volumul de date care s circule pe reea n urma elaborrii unui rspuns; o condiionare de genul dac s-a schimbat ceva i 8

posibilitatea de a prelua numai o parte din acesta. De exemplu, o cerere de genul: GET www.xxx.ro/?cerere HTTP/1.1 If-Modified-Since: Wed, 24 Mar 1999 1:00:00 GMT va aduce ceea ce s-a cerut numai dac s-a modificat ceva dup data i ora specificate n parametrii metodei. HEAD este o metod similar cu GET, folosit n principiu pentru testarea validitii i/sau accesibilitii unei resurse, sau pentru a afla dac s-a schimbat ceva. Sintaxa este similar metodei GET; spre deosebire de GET ns, datele eventual produse de resurs n urma cererii nu snt transmise; doar caracteristicile acestora, i un cod de succes sau eroare. Ceva de genul dac i-a cere s execui cererea mea, ce mi-ai rspunde?. POST este metoda prin care resursei specificate n cerere i se cere s i subordoneze datele incluse n entitatea care trebuie s nsoeasc cererea. Cu POST se poate aduga un fiier unui anumit director, se poate trimite un mesaj prin pot electronic, se poate aduga un mesaj unui grup de tiri, se pot aduga date unei baze de date existente, etc. Metoda POST este general; care snt procesele pe care un anumit server le accept sau cunoate i snt strict specifice. PUT este o metod care cere serverului ceva mai mult dect POST: s stocheze/memoreze entitatea cuprins n cerere cu numele specificat n URI. Dac resursa specificat exist deja, entitatea nou trebuie privit ca o versiune modificat care ar trebui s o nlocuiasc pe cea existent. Serverul, bineneles, va accepta sau nu aceast cerere, funcie de drepturile de acces pe care i le-a acordat clientului, i va rspunde cererii cu informaii corespunztoare (s-a fcut, nu pot, nu ai voie s faci treaba asta etc.). Pentru a evita situaii care s duc la ncrcarea excesiv si nejustificat a reelei - de exemplu, un client care vrea s posteze un text de 10 MB, fr s in seama de faptul c serverul nu mai are att loc att o cerere de tipul POST ct i una de tipul PUT se desfoar n doi timpi: nti, clientul trimite numai parametrii metodei, fr s trimit datele efective pe care le vrea postate. Dup care ateapt 5 secunde. n acest timp, dac serverul rspunde, clientul ia n seam i analizeaz rspunsul serverului (iar dac acesta este nu mai am loc, datele nu se mai transmit). Dac nu sosete nici un rspuns n timpul de ateptare, se consider implicit c serverul accept datele i acestea snt transmise de ctre client. PATCH este o metod similar lui PUT, dar nu conine toate datele care s defineasc resursa, ci numai diferenele fa de versiunea existent pe server. Cu toate informaiile necesare care s i permit serverului s reconstruiasc o versiune la zi a resursei. COPY, MOVE i DELETE snt metode prin care se cere ca resursa specificat n URIul din cerere s fie copiat n locaiile specificate ca parametri pentru metod, mutat acolo sau respectiv doar tears. LINK i UNLINK snt metode prin care resursa specificat n cerere este legat/dezlegat de alte resurse, stabilind una sau mai multe relaii cu acestea din urm, specificate ca parametrii pentru metod. Ar putea fi de exemplu un index pentru o baz de date, un cuprins pentru un set de documente, etc. TRACE este o metod care i permite clientului s vad cum ajung cererile sale la server, pentru a verifica/diagnostica conexiunea, pentru a se verifica pe sine sau pentru a 9

determina felul n care eventualele proxy-uri de pe parcurs au modificat cererea iniial. Serverul, n rspuns la aceast cerere, va trimite n ecou cererile care i vin de la client, fr s le mai trateze ca cereri reale. WRAPPED este o metod care contrazice principiul protocolului de a trimite totdeauna o singur cerere i a atepta un singur rspuns. Via WRAPPED, mai multe cereri, care n mod obinuit ar fi succesive, snt mpachetate ntr-una singur. Iar o alt aplicare a metodei intete msuri de securizare - o cerere poate fi cifrat i transmis prin metoda WRAPPED, ceea ce va determina serverul s acioneze n doi pai: nti s descifreze cererea real, iar apoi s i dea curs acesteia.

10