HTTP
De la Wikipedia, enciclopedia liberă
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 aplicaţie. Realizarea şi evoluţia sa este coordonată de către World Wide Web Consortium (W3C).
Cuprins |
[modifică] Modul de funcţionare
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.
[modifică] Transferul argumentelor
Deseori utilizatorul doreşte să transmită informaţii speciale la website. Aici HTTP pune la dispozitie 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 [1].
Exemplu: la pagina de start dela 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: 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
[modifică] 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 - contiunuă:
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.
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 adunata/receptionata de la un server local.
204 - fara continut:
Server-ul a indeplinit cererea si nu e nevoit sa intoarca raspunsul, dar ar dori sa raspunda printr-o informaţie recentă, gen meta.
205 - conţinut refăcut:
Cererea a fost îndeplinita ş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 îndeplinita 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ă.
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ă redirectţ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ărte 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.
307 - redirectare temporară:
Sursa cerută se află temporar la un diferit URI. Din moment ce redirectarea poate fi modificata ocazional, utilizatoarul ar trebui să continuie 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 raspunsul 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.
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 facând răspunsul unei cereri „Direcţionat/condus”, serverul ar trebui, în acest caz sa includă o afişare cu o explicaţie a situaţiei de eroare, fie că e temporara 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.
[modifică] Versiuni
- 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;
- HTTP/1.0 – versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătăţiri;
- 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.
[modifică] Metode
Metodele disponibile sunt :
- GET: este cea mai folosită metodă, fiind utilizată atunci când serverului i se cere o resursă.
- HEAD: se comportă exact ca metoda GET, dar serverul returnează doar antetul resursei, ceea ce permite clientului să inspecteze antetul resursei, fără a fi nevoit să obţină şi corpul resursei.
- PUT: metoda este folosită pentru a depune documente pe server, fiind inversul metodei GET.
- POST: a fost proiectată pentru a trimite date de intrare către server.
- DELETE: este opusul metodei PUT.
- TRACE: este o metodă folosită de obicei pentru diagnosticare, putând da mai multe informaţii despre traseul urmat de legătura HTTP, fiecare server proxy adăugându-şi semnătura în antetul Via.
- OPTIONS: este folosită pentru identificarea capacităţilor serverului Web, înainte de a face o cerere.
- CONNECT: este o metodă folosită în general de serverele intermediare.
[modifică] Exemplu
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
