MINISTERUL EDUCAŢIEI, CERCETĂRII, TINERETULUI ŞI SPORTULUIGRUP ŞCOLAR “FERDINAND I”, CURTEA DE ARGEŞ

PROIECT DE DIPLOMĂNIVEL 3

SPECIALIZAREA: TEHNICIAN OPERATOR TEHNICĂ DE CALCUL

INDRUMĂTOR: ABSOLVENT: GORGOS E.Ing. MELANIA PLETEA IONUŢ

2012

TEMA:

PROTOCOLUL HTTP

CUPRINS

Argument ........................................................................................pag.4

1.1 Terminologie...................................................................................pag.5

1.2 Structura unui server web sub Linux. Modul de funcționare.........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 Generalități. 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 conlucrând în

medii distribuite. HTTP a început sa fie proiectat si utilizat din anul 1990, dezvoltându-se

împreună cu spațiul WWW. Prima versiune, referita ca HTTP/0.9, a reprezentat un simplu

protocol de transfer de date prin Internet. Următoarea versiune, HTTP/1.0, definita de RFC 1945,

a îmbunătățit transferul de mesaje, permițându-se mesaje în format MIME (Multipurpose

Internet Mail Extensions), conținând meta-informații despre datele transmise si despre semantica

dialogului cererilor si răspunsurilor dintre clienții si serverele Web.

A urmat HTTP/1.1 care oferă mai multe funcționalități suplimentare, precum mecanisme

de căutare, adnotare si actualizare, având suport pentru URI (Uniform Resource Identifier),

specificând adresele ca locație (prin URL) sau prin nume (via URN). HTTP de asemeni este

utilizat ca protocol generic pentru comunicarea între agenții utilizator si porțile (gateways) către

alte sisteme Internet, incluzând 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 aplicații.

Protocolul HTTP este un protocol de tip cerere/răspuns, comunicațiile decurgând peste

conexiunile TCP/IP, portul standard de acces fiind portul 80.

HTTP (Hypertext Transfer Protocol) este metoda cea mai des utilizată pentru accesarea

informaţiilor în Internet care sunt păstrate pe servere World Wide Web (WWW). Protocolul

HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu

conţine partea de protocol, aceasta se consideră ca fiind http. HTTP presupune că pe calculatorul

destinaţie rulează un program care înţelege protocolul. Fişierul trimis la destinaţie poate fi un

document HTML (abreviaţie de la HyperText Markup Language), un fişier grafic, de sunet,

animaţie 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

aplicaţie. Realizarea şi evoluţia sa este coordonată de către World Wide Web Consortium

(W3C).

Cap.1. PROTOCOLUL HTTP

1.1. TERMINOLOGIE

HTTP - Hypertext Transfer Protocol

World Wide Web este alcătuit 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 afişat, imagini grafice, comenzi de formatare şi

hiperlegături spre alte documente situate altundeva în Web. Documentele HTML sunt afişate 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ă tranzacţiile dintre un client Web şi un server Web. HTTP este un protocol

destinat stratului aplicaţie. Protocolul HTTP face uz în mod transparent de DNS şi de alte

protocoale Internet pentru a forma conexiuni între clientul şi serverul Web astfel încât

utilizatorul cunoaşte numai numele domeniului şi numele documentului însuşi.

HTTP este, în esenţă, un protocol nesigur. Informaţiile pe suport text sunt transmise

„în clar", între client şi server. Pentru a satisface necesitatea unor reţele Web sigure există

alternative precum Secure HTTP (S-HTTP) sau Secure Sockets Layer (SSL).

Cererile unui client Web către un server Web sunt orientate spre conexiune, deci sunt

persistente. Odată ce clientul a primit conţinutul unei pagini HTML, conexiunea nu mai este

activă. Executarea unui clic în documentul HTML reactivează legătura fie către serverul original

(dacă într-acolo indică hiperlegătura), fie către un alt server, situat altundeva.

Vor fi folosiţi în cele ce urmează următorii termeni:

conexiune

Un circuit virtual la nivelul transport stabilit între doua programe care doresc sa comunice.

mesaj

Unitatea de baza a unei comunicații HTTP, constând dintr-o secvență structurata de octeți,

transmisia printr-o conexiune.

5

cerere

Un mesaj de cerere HTTP

răspuns

Un mesaj de răspuns HTTP.

resursa

Un obiect de date sau serviciu care poate fi identificat de un URI. Resursele pot avea

reprezentări multiple (e.g. formate, mărimi, rezoluții, etc.).

entitate

Informația transferată într-o operație de cerere sau de răspuns. O entitate cuprinde atât meta-

informații, cât si conținutul propriu-zis.

reprezentare

O entitate inclusa într-un răspuns ce reprezintă o negociere între client si server.

negociere

Mecanism de selectare a reprezentării potrivite a unei date solicitate.

client

Un program care stabilește conexiuni cu scopul de a trimite cereri.

agent-utilizator

Clientul ce inițiază o cerere (navigator, editor, robot de traversare Web). Navigatoarele cele

mai cunoscute sunt Netscape Navigator, Internet Explorer, Arena, Mozaic.

Server

O aplicație care accepta conexiuni, răspunzând la anumite cereri transmise de clienți. Un

program poate juca rol atât de server, cât si de client. Un server se poate comporta ca server

inițial, poarta, tunel sau Proxy Web în funcție de natura cererii. Cele mai cunoscute servere Web

6

sunt: Apache, Netscape Enterprise Server, Sun Web Server, Windows NT Web Server,

Stronghold.

Proxy (intermediar)

Un program intermediar care rulează ca server, cât si drept client pentru a transmite cereri

altor servere. Cererile trimise unui Proxy pot fi rezolvate intern sau transmise mai departe, către

alte servere (posibil translatate). Un proxy trebuie sa implementeze cerințele de server si de

client ale specificației HTTP.

poarta

Un server care lucrează ca intermediar pentru alte servere, în mod transparent, fiind si un

translator de protocoale.

tunel

Un program intermediar funcționând ca mijlocitor între doua conexiuni.

cache

Un depozit local de memorare a mesajelor (datelor) de răspuns si un subsistem de control al

acestuia. Memoria cache reduce timpul de răspuns si congestia rețelei. Orice client si server

poate include un cache.

7

1.2. STRUCTURA UNUI SERVER WEB SUB LINUX. MODUL DE FUNCŢIONARE

În figura următoare 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ă afişeze 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 răspuns la cererea HTTP-GET. Informaţii suplimentare ca de ex. indicaţii

pentru browser, limba dorită ş.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma

cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în

(X)HTML, cu fişiere ataşate ca imagini, fişiere de stil (CSS), scripturi (Javascript), dar pot fi şi

pagini generate dinamic (SSI, JSP, PHP şi ASP.NET). Dacă dintr-un anumit motiv informaţiile

nu pot fi transmise, atunci serverul trimite înapoi un mesaj de eroare. Modul exact de desfăşurare

a acestei acţiuni (cerere şi răspuns) este stabilit în specificaţiile HTTP.

8

1.3. TRANSFERUL ARGUMENTELOR

Deseori utilizatorul doreşte să transmită informaţii speciale la website. Aici HTTP pune la

dispoziție două posibilităţi:

Transferul datelor în combinaţie cu o cerere pentru o resursă (HTTP-metoda "GET")

Transferul datelor în combinaţie 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 alcătuite din

numele parametrului, semnul = şi valoarea parametrului. Rareori se mai utilizează şi semnul ;

pentru separarea înregistrărilor listei .

Exemplu: la pagina de start de la Wikipedia.ro utilizatorul introduce în câmpul de căutare

termenul "pisici", alege categoria "articole" şi apasă butonul de căutare. Atunci browserul trimite

următoarea 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 ataşează pagina. Astfel serverul află că utilizatorul doreşte să vadă articole despre

pisici. Serverul prelucrează cererea, dar nu trimite un fişier ci redirectează browserul cu un

Location-Header spre pagina dorită:

HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:12:44 GMT Location:

9

http://ro.wikipedia.org/wiki/pisici

Browserul execută indicaţia şi, pe baza noilor informaţii, emite o nouă cerere: GET /wiki/pisici

HTTP/1.1 Host: ro.wikipedia.org. Serverul răspunde ş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Ã!õ²ÌÇlô²¬¬ìuVò*ÉÖ– 3.r`Î+.F”xÊ!ÿ

×.ý.ö´7ý“ü’t.ó"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 răspunde astfel:

10

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 câteva dintre erorile conţinute):

1xx - erori informaţionale : această clasă a status-ului indică un răspuns provizoriu al

serverului şi conţine numai linia de status (de răspuns) sau alte aplicaţii opţionale. Nu

sunt aplicaţii necesare pentru acestă clasa de răspuns/status. Aceste status-uri pot fi

ignorate.

100 - continuă:

Utilizatorul ar trebui să îşi continuie cererea/acţiunea. Acest răspuns provizoriu este

folosit pentru a informa utilizatorul ca partea iniţială a cereri a fost receptată şi că deocamdată nu

a fost refuzată de server. Utilizatorul ar trebui să continuie şi să ignore acest răspuns.

101 - schimbare protocol:

Server-ul înţelege şi are intenţia de a de a îndeplini cererea utilizatorului, răspunând prin această

eroare că părţi ale server-ului sunt în proces de schimbare/mutare. Server-ul va schimba

protocolul imediat după ce răspunsul pentru linia 101 va fi terminată. Protocolul ar trebui

schimbat doar în momentul în care acest lucru este avantajos şi se permite.

2xx - răspuns reuşit : clasa de răspuns/status ce indică utilizatorului că cererea a fost

primită, înţeleasă şi acceptată cu succes.

200 - ok:

Această cerere a fost executată cu succes. Informaţia a revenit cu un răspuns pozitiv,

indiferent de modul în care s-a făcut cererea.

201 - creat/realizat:

Cererea a fost îndeplinită având ca rezultat crearea unui nou rezultat. Noul rezultat poate

fi referit/raportat de către URI-uile înapoiate la intrarea răspunsului.

11

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 alţi utilizatori,

fără a cere conexiunii clientului să insiste până ce procesul/cererea e completă.

203 - informaţie neautorizată:

Informaţia returnată/revenită nu e definitivă ca fiind din server-ul principal, ci e adunată

recepționată de la un server local.

204 - fără conținut:

Server-ul a îndeplinit cererea şi nu e nevoit sa întoarcă răspunsul, dar ar dori să răspundă

printr-o informaţie recentă, gen meta.

205 - conţinut refăcut:

Cererea a fost îndeplinită şi ar trebui ca browser-ul să poată modifica/reseta modul de

vizualizare a documentului ce a cauzat această cerere către server.

206 - conţinut parţial:

Serverul a îndeplinit parţial cererea de primire de la sursă.

3xx - redirectări : această clasă de răspuns/status indică faptul că acţiunile următoare vor

trebui făcute de browser pentru a putea fi îndeplinită cererea. Cererea ar putea fi

direcţionată de browser fără a interacţiona cu utilizatorul dacă şi numai dacă metoda

folosită în cea de a doua cerere este „Primit/recepţionat” sau „Direcţionat/condus”.

300 - diferite/multiple alegeri:

Sursa cererii corespunde unor seturi de descrieri, fiecare cu locaţii specifice, iar browser-

ul dat fiind negocierea informaţiei, primeşte răspunsul astfel încât utilizatorul/browser-ul să

poată alege modul dorit astfel încât redirectarea să fie spre acea locaţie. În cazul în care cererea a

fost de tip „Condus/trimis”, răspunsul ar trebui să includă o intrare cu lista caracteristicilor şi

locaţiilor de unde utilizatorul sau browser-ul poate alege sursa cea mai apropiată.

12

301 - modificat/mutat permanent:

Cererii i-a fost atribuite o sursă nouă şi permanentă URI iar cererile următoare ar trebui

să folosească una din sursele returnate URI. Dacă acest mesaj/cod este primit ca răspuns al unei

cereri tip „Primit/recepţionat” sau „Direcţionat/condus”, browser-ul nu trebuie să redirecţioneze

automat cererea, doar dacă nu poate fi confirmată de către utilizator.

302 - găsit:

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 recepţionat ca răspuns al unei

cereri alta decât „Primit/recepţionat” sau „Direcţionat/condus”, browser-ul nu trebuie să

redirecteze automat cererea dacă aceasta nu poate fi confirmată de către utilizator.

303 - vezi alta sursă:

Răspunsul cererii poate fi găsit sub un diferit URI şi ar trebui să fie recepţionat folosind

metoda „Primit/recepţionat” de la acea sursă.

304 - nemodificat:

În cazul în care clientul a efectuat o cerere de tip „Primit/recepţionat” şi accesul este

permis, dar documentul nu a fost modificat, serverul ar trebui să răspundă cu acest mesaj/status.

305 - foloseşte proxy:

Cererea trebuie accesată printr-un proxy dat de către câmpul de locaţie. Acesta este dat de

către URI. Beneficiarul va repeta acestă unică cerere prin intermediul unui proxy. Răspunsul 305

va fi generat doar de către serverul de origine.

306 (nefolosit):

Acest mesaj/status a fost folosit într-o vesiune anterioară a specificaţiilor deci nu mai este

folosit, el fiind reţinut.

13

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 acţiuni.

4xx - erori ale utilizatorilor : această clasă de mesaje/statusuri este folosită în cazurile în

care utilizatorul ar putea greşi formularea cererii. Excepţia fiind răspunsurule pentru

cererile tip „Direcţionat/condus”, atunci serverul ar trebui să conţină o intrare cu o

explicaţie a situaţiei erorii şi dacă e o eroare temporară sau pemanentă. Aceste răspunsuri

sunt aplicabile pentru orice fel de cerere. Browser-ele ar trebui să arate orice intrare

cerută de utilizator.

400 - cerere greşită:

Cererea nu a putut fi înţeleasă/percepută de către server din cauza unei sintaxe

greşite/incomplete. Utilizatorul ar trebui să nu repete cererea fără ca aceasta să suporte

modificări.

401 - neautorizat:Cererea necesită autentificarea/înregistrarea utilizatorului. Răspunsul trebuie

să includă WWW - câmp de autentificare conţinând o somaţie aplicabilă utilizatorului.

Utilizatorul poate repeta cererea. Dacă cererea deja includea câmpul de autorizare, atunci

răspunsul 401 indică faptul că autorizarea a fost refuzată. Dacă răspunsul 401 conţine aceeaşi

somaţie ca răspuns principal iar browser-ul a executat autentificarea cel puţin o dată, atunci

utilizatorul ar trebui să i se prezinte intrarea dată în răspuns, din moment ce aceasta include

informaţii relevante.

402 - necesită plata:

Rezervat pentru utilizare ulterioară.

403 - interzis:

Serverul a înţeles cererea, dar refuză să o îndeplinească. Autorizarea nu ajută în nici un

caz, iar cererea nu ar mai trebui repetata.

14

404 - negăsit:

Serverul nu a găsit nimic care să corespundă cererii URI. Nu se dau indicaţii despre

condiţia temporară sau permanentă.

405 - metodă nepermisă:

Metoda specificată în linia de cerere (Request-Line) nu este permisă de către sursa

identificată după URI-ul cerut.

406 - neacceptat:

Sursa identificată de cerere este capabilă să genereze doar intrări care au conţinut specific

neacceptat de către condiţiile de acceptare trimise prin cerere.

407 - autentificare prin proxy:

Mesajul este similar celui 401, dar indică situaţia în care utilizatorul trebuie să se

autentifice prin proxy.

408 - cerere expirată:

Utilizatorul nu a făcut cererea în timpul în care serverul era pregătit sa o aştepte. Se poate

repeta cererea fără modificări prealabile.

5xx - erori de server : răspunsurile/status-urile ce încep cu unitatea/cifra 5 indică cazurile

în care serverul e conştient de greşelile produse sau e incapabil să execute cererea.

Excepţie făcând răspunsul unei cereri „Direcţionat/condus”, serverul ar trebui, în acest

caz să includă o afişare cu o explicaţie a situaţiei de eroare, fie că e temporară sau

permanentă.

500 - eroare internă de server:

Server-ul a întâmpinat o condiţie neaşteptată şi o previne spre a putea îndeplini cererea.

501 - neîndeplinit/nerecunoscut:

15

Server-ul nu poate suporta funcţionalitatea cerută pentru a putea îndeplini cererea. Acesta

este răspunsul specific în cazurile în care server-ul nu recunoaşte metoda de cerere şi nu e

capabil să o suporte indiferent de mijloc/resursă.

502 - poartă/ieşire greşită:

Server-ul, în timp ce încerca să se comporte ca o poartă/ieşire sau ca un proxy, a

recepţionat un răspuns 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 supraîncărcări

sau a serviciilor de întreţinere a server-ului ce au loc în acel moment. Aceasta este o stare

temporară şi în curând va fi remediată.

504 - poartă/ieşire expirată:

Server-ul, în timp ce încerca să se comporte ca o poartă/ieşire sau ca un proxy, nu a

primit un răspuns 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 accesării în încercarea de a

termina/îndeplini cererea.

505 - versiunea HTTP nu e suportată/susţinută:

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

aceeaşi versiune cu cea a clientului.

16

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;

2. HTTP/1.0 – versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătăţiri;

3. HTTP/1.1 – versiune de îmbunătăţire ş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 stabileşte o nouă conexiune TCP înaintea cererii, iar după transmiterea răspunsului

conexiunea trebuie închisă. Astfel dacă un document HTML cuprinde 10 imagini, vor fi necesare

11 conexiuni TCP, pentru ca pagina să fie afişată complet (în browser). La versiunea 1.1 se pot

emite mai multe cereri şi răspunsuri pe aceeaşi 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 încărcare a paginii. La aceasta se adaugă şi faptul că

versiunea 1.1 poate relua şi continua transferuri întrerupte.

La HTTP se pierd informaţiile cererilor vechi (deci este un protocol fără reţinerea stării). Prin

utilizarea de cooki-uri în header, se pot realiza însă aplicaţii care pot utiliza informaţii de stare

(opţiunile utilizatorului din sesiunea actuală, coş de cumpărături ş.a.). Chiar şi o recunoaştere a

utilizatorului este astfel posibilă. În mod normal se pot citi informaţiile transmise care parcurg

reţeaua 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 reînnoieşte complet conţinutul ferestrei browser-ului. Noua versiune

permite pe lângă 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 urmări calea spre

webserver, şi verifica dacă datele au fost corect transferate. Astfel se poate urmări calea prin

diferite proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicaţie.

17

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 informaţii despre opţiunile de comunicare disponibile într-un dialog

cerere/raspuns.

GET

Reprezintă o cerere de accesare a unor informaţii (entitati) identificate de Request-URI.

Semantica metodei GET se schimba în cerere conditionată dacă mesajul de cerere include

câmpuri antet If-Modified-Since, If-Match, If-Range. Daca se specifica un câmp Range, atunci

GET va specifica o cerere partială.

HEAD

Este similară cu GET, dar serverul va returna un mesaj având informatii doar în antetul lui.

Meta-informaţtiile din antetele HTTP din răspunsul la o cerere HEAD vor fi identice cu cele din

răspunsul la o cerere GET. Metoda HEAD este folosită deseori pentru testarea validitaţii,

accesibilitaţii si modificărilor recente ale unei legaturi hipertext. Pentru documente HTML, o

cerere HEAD va avea ca răspuns doar antetul paginii, adică informaţiile 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 funcţtiile: adnotarea resurselor,

trimiterea unui mesaj într-o listă de ştiri, trimiterea datelor unui formular Web, extinderea unei

baze de date printr-o operaţiune de adăugare. Semantica exactă a metodei este definită de server.

Răspunsul 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. Diferenţa 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ă către alt protocol, o entitate separată acceptând adnotări.

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

1.8. EXEMPLU DE HTTP

Cererea clientului:

GET / HTTP/1.1

Host: www.example.com

Răspunsul 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 operaţiuni de plată pe World Wide Web şi pentru operaţiunile "sensibile" din

sistemele de informaţii corporative.HTTPS nu trebuie confundat cu Secure HTTP (S-HTTP)

specificat în RFC 2660.

2.2. DESCRIERE HTTPS

HTTPS este un protocol de comunicaţie destinat transferului de informaţie criptată prin

intermediul WWW. A fost dezvoltat din necesitatea de a proteja de intruşi transferul datelor prin

HTTP - un protocol "clear-text", prin care datele de pe server-ul web sunt transmise browser-ului

client în clar, posibilităţile de a intercepta acest transfer constituind tot atâtea posibilităţi de a

accesa şi utiliza fără restricţii informaţiile respective. HTTPS nu este altceva decât HTTP

"încapsulat" cu ajutorul unui flux SSL/TLS - datele sunt criptate la server înainte de a fi trimise

clientului, astfel încât simpla interceptare a acestora pe traseu să nu mai fie suficientă pentru a

avea acces la informaţii. HTTPS este în acelaşi timp o metodă de autentificare a server-ului web

care îl foloseşte, prin intermediul aşa-numitelor "certificate digitale" - o colecţie 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 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 î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