Protocolul HTTP [PDF]

Zitiervorschau

MINISTERUL EDUCAŢIEI, CERCETĂRII, TINERETULUI ŞI SPORTULUI

GRUP ŞCOLAR “FERDINAND I”, CURTEA DE ARGEŞ

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

INDRUMĂTOR: 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 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 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

5

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

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 metainformaț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

6

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

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

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ă: 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ă 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:

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

11

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.

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:

12

Sursa cererii corespunde unor seturi de descrieri, fiecare cu locaţii specifice, iar browserul 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ă.

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

306 (nefolosit): Acest mesaj/status a fost folosit într-o vesiune anterioară a specificaţiilor deci nu mai este folosit, el fiind reţinut.

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:

14

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.

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 15

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

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 SlowStart 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" 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 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

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

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

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