protocolul http
TRANSCRIPT
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