CATEGORII DOCUMENTE |
Protocolul HTTP
(referat)
HTTP( HyperText Transfer Protocol ) este protocolul folosit pentru a transmite hipermedia in World Wide Web. Astfel browser-ele precum si server-le folosesc acest protocol pentru a transmite fisiere ce contin imagini, sunete, surse de pagini HTML(hipertext) si alte tipuri de date.
Pentru a nu apare erori de interpretare a fisierelor transmise, este necesar ca, atat server-ul cat si browser-ul sa cunoasca tipul fisierului transmis.
Astfel, in antetul documentului transportat prin intemediul protocolului HTTP, se gaseste specificatia MIME (Multipurpose Internet Mail Extensions - extensiile multifunctionale pentru posta electronica).
Inainte de specificatia MIME a existat specificatia tehnica pentru transmiterea de mesaje intre calculatoare (e-mail). Sintaxa sa este scrisa in RFC 822 (Request for Comments) de D. H. Crocker, 1982. RFC 822 prezinta dezavantajul ca nu precizeaza mecanisme de transfer al mesajelor ce contin fisiere audio si video, texte in limbi slave sau asiatice. MIME furnizeaza specificatia Internet pentru transferul acestor tipuri de date Web.
Specificatia MIME defineste formate pentru fisiere de imagine, animatie, audio, binare, aplicatie si alte tipuri de fisiere multimedia. Un alt avantaj major al specificatiilor MIME este posibilitatea de a defini formate proprii pentru fisiere care pot fi utilizate pentru comunicarea cu un server (daca serverul recunoaste formatul respectiv).
In cadrul fiecarui antet transmis de server, este precizat atat tipul cat si subtipul MIME al fisierului.
In urmatorul tabel sunt prezentate tipurile si subtipurile MIME standard:
Tipuri MIME |
Text |
Audio |
Video |
Multipart |
Imagine |
Aplicatie |
Subtipuri MME |
Html |
32 kad pcm |
mpeg |
Date formatate |
jpeg |
ms word |
Text simplu (ASCII) |
basic |
quicktime |
Set antet |
gif |
Mesaj activ |
|
Text cu formatari (RTF - Rich Text Format ) |
Amestecate |
tiff |
Postscript |
|||
Valori separate prin tabulatori |
ief |
Matematica |
Cand un fisier este transmis de catre un server Web pe Internet catre o aplicatie client, server-ul include in fisier( intr-un antet de tip MIME) informatii despre formatul fisierului respectiv. Aplicatia care receptioneaza fisierul respectiv utilizeaza informatiile din antet pentru a identifica tipul datelor din corpul fisierului.
Tipul si subtipul MIME se afla in campul Content-Type din antet. Cand un server Web se pregateste sa transmita un fisier catre un browser, serverul utilizeaza de obicei, extensia fisierului pentru a identifica tipul si subtipul MIME. Astfel, serverul Web furnizeaza browserului Web un antet cu tipul continutului pentru a identifica formatul MIME.
Exemplu : Un server poate reprezenta un tip si un subtip MIME :
Content-type : movie/mpeg
In acest caz, tipul MIME este movie, iar subtipul este mpeg. Astfel, browserul va sti ca serverul ii transmite un fisier video in format mpeg ce urmeaza sa fie redat.
Se stie ca o conexiune FTP se opreste doar daca este parasita conexiunea sau apare o eroare. O astfel de conexiune se numeste conexiune statica. Se poate spune, deci, ca protocolul FTP-ul este static.
Spre deosebire de acesta din urma, HTTP-ul nu este static. Drept urmare, serverul si browserul stabilesc o conexiune la fiecare operatie HTTP, conexiune ce va fi inchisa dupa ce operatia va fi terminata.
De exemplu, daca browserul solicita serverului incarcarea unei pagini in format HTML, este creeata o conexiune care va fi inchisa imediat ce o copie a fisierului va fi receptionata. Daca pentru vizualizarea paginii HTML respective este necesara incarcarea unui fisier ce contine o imagine, se va creea o noua conexiune pentru receptarea fisierului cu imaginea respectiva. Bineinteles, conexiunea va fi inchisa imediat dupa receptionarea fisierului.
O singura operatie HTTP se numeste tranzactie. HTTP utilizeaza o conexiune TCP/IP care este intretinuta numai pe durata unei singure tranzactii. Nici browserul, (clientul) nici serverul nu sunt responsabile cu memorarea ultimei stari a unei conexiuni. Apelarea unei legaturi hipertext va implica ca browserul sa treaca de la un site la altul. Stiind ca oricand se poate utiliza o hiperlegatura pentru a parasi site-ul, serverul presupune ca s-a parasit site-ul si intrerupe conexiunea. Daca "se ramane in site", serverul creaza o noua conexiune. Daca se iese ("se paraseste site-ul"), serverul nu are nimic de facut pentru ca conexiunea este deja intrerupta. Eliberarea conexiunilor in acest mod permite serverului sa raspunda si altor clienti, determinand cresterea eficientei.
Recent, s-a experimentat totusi, pe servere, o tehnica de ascundere a conexiunilor (connection caching), prin care un server nu inchide conexiunea imediat dupa furnizarea raspunsului. Prin operatia de "ascundere" a conexiunii respective, serverul poate raspunde rapid unui client daca acesta "reviziteaza" locatia. Datorita faptului ca site-urile Web devin tot mai complexe, oferind utilizatorilor tot mai multe legaturi "locale", tenica de ascundere a conexiunii (pentru legaturile locale cunoscute) va imbunatati performantele.
Protocolul HTTP accepta formate dinamice. Astfel, clientii si serverele determina in mod dinamic formatele de document, adica cand un browser contacteaza un server, browserul trimite serverului o lista de formate pe care le recunoaste. Serverul raspunde prin trimiterea de date care utilizeaza formatul corespunzator, daca este posibil. Astfel, serverele si clientii pot utiliza formate de date proprii (personalizate) pentru schimbul de date.
Cand un server trimite un document prin Web, acesta poate include informatii despre fisier (numite metainformatii) in antetul HTTP care precede fisierul. Programul care receptioneaza datele poate utiliza informatia din antet pentru interpretarea datelor. Astfel, receptorul obtine date despre datele care vor sosi.
Prin utilizarea informatiilor continute in antetul HTTP, aplicatiile negociaza formatele pe care le vor utiliza pentru transferul de obiecte. Daca o aplicatie nu poate recunoaste informatia continuta intr-un antet HTTP, in general, o va ignora. Intrucat aplicatiile ignora formatele pe care nu le recunosc, se pot defini astfel noi protocoale in Web fara a compromite integritatea HTTP.
HTTP-ul este un protocol lizibil, datorita faptului ca se bazeaza pe text, nefiind necesara prezenta unui decodificator pentru citire. Asfel pot fi afisate in browsere informatii despre starea tranzactiei HTTP.
Cele patru etape ale unei tranzactii HTTP:
Clientii si serverele utilizeaza HTTP pentru cereri si raspunsuri. Serverul si clientul mentin conexiunea TCP/IP numai pe durata unei tranzactii (HTTP nu este static), iar serverul, in mod normal, inchide conexiunea dupa terminarea tranzactiei. Deci se pot reconstitui cele patru etape ale unei tranzactii HTTP :
Etapa I : Stabilirea conexiunii. Pentru a schomba informatii, serverul si browserul trebuie sa stabileasca o conexiune TCP/IP. Protocolul HTTP foloseste portul 80, dar pot fi utilizate si alte porturi daca serverul si clientul stabilesc de comun acord acest lucru.
Etapa a II-a : Clientul emite o cerere. Fiecare cerere HTTP emisa de un client catre un server Web incepe cu o metoda, urmata de adresa URL a unui obiect. Clientul completeaza aceasta informatie cu versiunea protocolului HTTP pe care il utilizeaza, urmat de CR, LF, optional urmate de informatie codificata intr-un anumit mod, sub forma unui antet. In final, browserul adauga un CR, LF la informatia precedenta, urmat optional de corpul entitatii (un document).
O metoda HTTP este o comanda utilizata de client pentru a specifica scopul cererii catre server. Metodele HTTP corespund unei resurse (identificate prin adresa sa URL). Clientul specifica si versiunea HTTP utilizata (de exemplu 1.0). Toate acestea (metoda, URL, versiunea protocolului HTTP) formeaza linia de cerere (Request - Line).
Clientul utilizeaza campul de antet al cererii (Request - Header) pentru a furniza informatii despre cererea in sine si despre clientul care transmite cererea catre server.
Etapa a III-a : Serverul emite un raspuns. Dupa ce un server Web primeste si interpreteaza un mesaj de cerere, serverul raspunde cu un mesaj de raspuns HTTP. Mesajul de raspuns incepe intotdeauna cu versiunea protocoului HTTP, urmata de un cod
de stare format din 3 cifre, si o fraza de motiv, un CR, LF si informatii optionale, codificate sub forma unui antet. In final, serverul adauga un CR, LF la informatiile precedente, urmat optional de corpul entitatii.
Codul de stare descrie posibilitatile serverului de a intelege si a satisface cererea clientului. Fraza de motiv este un text scurt de descriere a codului de stare. Versiunea protocolului HTTP, codul de stare si fraza de motiv formeaza impreuna linia de stare.
Un antet de raspuns poate contine informatii specifice legate de resursa solicitata, plus eventuale declaratii MIME care pot fi necesare pentru livrarea raspunsului. Cand un server Web trimite un antet de raspuns unui client, include in mod normal aceleasi informatii furnizate de antetul cererii clientului.
Etapa a IV-a : Serverul termina conexiunea. Dupa rezolvarea cererii clientului, sarcina serverului este terminarea conexiunii TCP/IP cu clientul. Totusi, atat clientul (click pe butonul Stop al browserului) cat si serverul (defectarea unui calculator) pot gestiona o inchidere neasteptata a conexiunii. In ambele cazuri, inchiderea conexiunii termina tranzactia curenta, indiferent de starea sa.
HTTP este un protocol generic, mesajele HTTP constand in cereri ale aplictiilor client catre server si raspunsuri trimise de server clientului. Mesajele de tip cerere/raspuns sunt de doua feluri: simple si complete.
In timpul incercarii de a se conecta la server precum si pe toata durata conexiunii, browserul afiseaza adnotari referitoare la fiecare faza a procesului, precum si codurile de stare care afiseaza informatii despre tentativele de cautare si de gasire a resurselor respective. Folosind aceste informatii putem stabili daca este cazul sa oprim conexiunea.
Prima cifra a codului de acces HTTP defineste clasa codului de raspuns. Exista cinci posibilitati pentru valorile primei cifre :
1xx : Informational - aceasta combinatie nu este utilizata dar este rezervata pentru o utilizare ulterioara.
2xx : Succes - actiunea a fost receptionata, inteleasa si acceptata cu succes.
3xx : Redirectare - pentru completarea cererii trebuie activata alta actiune.
4xx : Eroare client - cererea contine sintaxa eronata sau nu poate fi indeplinita
5xx : Eroare server - serverul a esuat in indeplinirea unei cereri aparent valide.
Tabelul urmator prezinta pricipalele coduri de stare ale serverelor Web:
Cod de stare |
Semnificatia |
200 |
OK |
201 |
Succes al comenzii POST |
202 |
Cerere a fost acceptata |
203 |
Cererea (GET sau HEAD) a fost indeplinita |
204 |
Cerere fara cotinut de returnat indeplinita |
300 |
Resursa a fost gasita in mai multe site-uri |
301 |
Resursa mutata permanent |
302 |
Resursa este mutata temporar |
304 |
Resursa nu a fost modificata |
400 |
Cerere eronata de la client |
401 |
Cerere neautorizata |
402 |
Cererea este contra cost |
403 |
Este interzis accesul la resursa |
404 |
Nu a fost gasita resursa |
405 |
Metoda nu este permisa de resursa |
406 |
Tipul resursei este inacceptabil |
410 |
Resursa nu este disponibila |
500 |
Eroare interna a serverului |
501 |
Metoda nu este implementata |
502 |
Poarta de aces este eronata sau serverul estesupraicarcat |
503 |
Serviciu indisponibil sau intarziere a raspunsului portii de acces |
504 |
Poarta de acces secundara sau intarziere raspuns server |
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1477
Importanta:
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved