Sunteți pe pagina 1din 23

MINISTERUL EDUCAIEI, CERCETRII, TINERETULUI I SPORTULUI

GRUP COLAR FERDINAND I, CURTEA DE ARGE

PROIECT DE DIPLOM
NIVEL 3 SPECIALIZAREA: TEHNICIAN OPERATOR TEHNIC DE CALCUL

INDRUMTOR: Ing. MELANIA PLETEA

ABSOLVENT: GORGOS E. IONU

2012

TEMA:
PROTOCOLUL HTTP

CUPRINS

Argument ........................................................................................pag.4
1.1 Terminologie...................................................................................pag.5 1.2 Structura unui server web sub Linux. Modul de funcionare.........pag.8 1.3 Transferul argumentelor..................................................................pag.9 1.4 Erori de HTTP...............................................................................pag.11 1.5 Versiuni HTTP..............................................................................pag.17 1.6 Formatul mesajelor de cerere........................................................pag.18 1.7 Descrierea metodelor.....................................................................pag.18 1.8 Exemplu de HTTP.........................................................................pag.20

2.1 Generaliti. Caracteristici HTTPS................................................pag.21 2.2 Descriere HTTPS...........................................................................pag.21

Bibliografie ...................................................................................pag.22

ARGUMENT

Protocolul de transport al hiper-textelor HTTP (Hyper-Text Transport Protocol) este un protocol bazat pe stiva de protocoale TCP/IP, destinat sistemelor hipermedia conlucrnd n medii distribuite. HTTP a nceput sa fie proiectat si utilizat din anul 1990, dezvoltndu-se mpreun cu spaiul WWW. Prima versiune, referita ca HTTP/0.9, a reprezentat un simplu protocol de transfer de date prin Internet. Urmtoarea versiune, HTTP/1.0, definita de RFC 1945, a mbuntit transferul de mesaje, permindu-se mesaje n format MIME (Multipurpose Internet Mail Extensions), coninnd meta-informaii despre datele transmise si despre semantica dialogului cererilor si rspunsurilor dintre clienii si serverele Web. A urmat HTTP/1.1 care ofer mai multe funcionaliti suplimentare, precum mecanisme de cutare, adnotare si actualizare, avnd suport pentru URI (Uniform Resource Identifier), specificnd adresele ca locaie (prin URL) sau prin nume (via URN). HTTP de asemeni este utilizat ca protocol generic pentru comunicarea ntre agenii utilizator si porile (gateways) ctre alte sisteme Internet, incluznd suport pentru protocoale ca SMTP (Simple Mail Transfer Protocol), NNTP (Network News Transfer Protocol), FTP (File Transfer Protocol), Gopher. n acest mod, HTTP permite accesul hipermedia la resurse disponibile din diverse aplicaii. Protocolul HTTP este un protocol de tip cerere/rspuns, comunicaiile decurgnd peste conexiunile TCP/IP, portul standard de acces fiind portul 80.

HTTP (Hypertext Transfer Protocol) este metoda cea mai des utilizat pentru accesarea informaiilor n Internet care sunt pstrate pe servere World Wide Web (WWW). Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adic, dac un URL nu conine partea de protocol, aceasta se consider ca fiind http. HTTP presupune c pe calculatorul destinaie ruleaz un program care nelege protocolul. Fiierul trimis la destinaie poate fi un document HTML (abreviaie de la HyperText Markup Language), un fiier grafic, de sunet, animaie 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 4

aplicaie. Realizarea i evoluia sa este coordonat de ctre World Wide Web Consortium (W3C).

Cap.1. PROTOCOLUL HTTP 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 clieni. Un program poate juca rol att de server, ct si de client. Un server se poate comporta ca server iniial, 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 cerinele 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 reelei. Orice client si server poate include un cache.

1.1.

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 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 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.

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 Location-Header spre pagina dorit: 9

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 Content-Type: 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

10

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.

11

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 con inut: 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:

12

Sursa cererii corespunde unor seturi de descrieri, fiecare cu locaii specifice, iar browserul 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. 13

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:

14

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 15

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.

16

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; 2. HTTP/1.0 versiune introdus n 1996 prin RFC1945, a adus numeroase mbuntiri; 3. 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 SlowStart 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" webdesignerii 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.

17

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.2.

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 If-Modified-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. Meta-informatiile 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>.

18

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 dintr-un PUT identific entitatea inclus n mesajul de cerere. O unica resursa poate fi identificat de URI-uri multiple.

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

TRACE Invoc o cerere de diagnosticare (trasaj).

19

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

20

Cap. 2. PROTOCOLUL DE COMUNICATIE HTTPS 2.1. GENERALIT I. CARACTERISTICI


Secure Hyper Text Transfer Protocol (sau HyperText Transfer Protocol/Secure, abreviat HTTPS) reprezint protocolul HTTP ncapsulat ntr-un flux SSL/TLS cu scopul de a se oferi o identificare criptat i sigur la server. Conexiunile HTPPS sunt folosite n mare parte pentru efectuarea de operaiuni de plat pe World Wide Web i pentru operaiunile "sensibile" din sistemele de informaii corporative.HTTPS nu trebuie confundat cu Secure HTTP (S-HTTP) specificat n RFC 2660.

2.2. DESCRIERE HTTPS


HTTPS este un protocol de comunicaie destinat transferului de informaie criptat prin intermediul WWW. A fost dezvoltat din necesitatea de a proteja de intrui transferul datelor prin HTTP - un protocol "clear-text", prin care datele de pe server-ul web sunt transmise browser-ului client n clar, posibilitile de a intercepta acest transfer constituind tot attea posibiliti de a accesa i utiliza fr restricii informaiile respective. HTTPS nu este altceva dect HTTP "ncapsulat" cu ajutorul unui flux SSL/TLS - datele sunt criptate la server nainte de a fi trimise clientului, astfel nct simpla interceptare a acestora pe traseu s nu mai fie suficient pentru a avea acces la informaii. HTTPS este n acelai timp o metod de autentificare a server-ului web care l folosete, prin intermediul aa-numitelor "certificate digitale" - o colecie de date pe care un browser o solicit server-ului pentru a putea ncepe transferul criptat; dac certificatul este emis de o autoritate cunoscut (de exemplu VeriSign), browser-ul poate fi sigur c server-ul cu care comunic este ceea ce pretinde a fi.

21

BIBLIOGRAFIE

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10 http://ro.wikipedia.org/wiki/HTTP http://ro.wikipedia.org/wiki/HTTPS 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 RealTime 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 n 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/

22