Sunteți pe pagina 1din 10

LICEUL TEHNOLOGIC „IOAN BOJOR”

POSTLICEALĂ PROTECȚIA PLANTELOR


ANUL I

SERVICIUL WEB „HTTP”


HyperText Transfer Protocol

= REFERAT =

Disciplina: Informatică
Profesor: Bungărdean Melania
Elev: Man Marius-Ioan
CUPRINS

1. INTRODUCERE ......................................................................................................................................................2
2. HTTP (HyperText Transfer Protocol)...........................................................................................................3
2.1 Hypertext Transfer Protocol (HTTP) ...............................................................................................3
2.2 World Wide Web (WWW)....................................................................................................................3
2.3 File Transfer Protocol (FTP) ...............................................................................................................3
2.4 Versiuni de HTTP.....................................................................................................................................4
2.5 Transferul argumentelor ......................................................................................................................4
2.6 Metode .........................................................................................................................................................5
2.7 Coduri de răspuns HTTP ......................................................................................................................6
3. BIBLIOGRAFIE .......................................................................................................................................................9

1
1. INTRODUCERE

În zilele noastre, cea mai utilizată metodă de a interacționa cu un server Web este aceea
a arhitecturii client/server bazată pe tehnologie Web. Procesul schimbului de informații utilizat
în tehnologia Web nu diferă de procesul implementat de arhitectura standard client/server, în
care programul server gestionează procesarea interogărilor recepționate de la programele
clienți.
În cadrul procesului de schimb de informații utilizat de tehnologiile web, programele
client sunt executate în programe de navigare web, care se găsesc de obicei pe stațiile de lucru
sub forma aplicațiilor auxiliare, pe post de clienți. Browser-ele web sunt utilizate pentru
vizualizarea și interpretarea imediată a documentelor web stocate pe server și pentru acces la
alte servicii speciale, precum:
• Copierea de fișiere de pe servere FTP (client FTP);
• Oferirea de sesiuni virtuale de server (Telnet);
• Acces prin meniuri la resursele calculatoarelor de la distanta (Gopher).

Accesul la aceste funcții speciale este posibil ținând cont de faptul că, încă de la început,
programele de navigare web au fost create pentru acces multi-protocol, pentru a oferi o interfață
unică pentru acces la mai multe resurse din rețea. La ora actuală, cele mai cunoscute navigatoare
web sunt Internet Explorer (Microsoft), Google Chrome (Google), Opera (Opera) și FireFox
(Open Source).
În cadrul schemei de interacțiune cu tehnologiile web, serverul web acționează ca un
program server principal. Acesta este lansat pe server și implementează procesarea
interogărilor care sunt transmise de către clienți, interacțiunea dintre clienții web și serverul
web fiind îndeplinită pe baza regulilor stabilite de protocolul HTTP (HyperText Transfer
Protocol). În momentul pornirii serverului web, acesta începe sa „asculte” sau sa controleze un
port logic din rețea, care, în mod standard pentru acestea, este cel cu numărul 80, și presupune
că toate mesajele transmise către acest port sunt destinate serverului web.
În momentul recepționării unei interogări de la clientul web, serverul web stabilește o
conexiune prin utilizarea TCP/IP și începe sa schimbe informații cu clientul prin protocolul
HTTP. în cazul în care clientul dorește acces la informații protejate de pe serverul web, serverul
poate cere să fie introduse un identificator și o parolă pentru utilizator, aceste documente web
protejate fiind astfel accesibile doar utilizatorilor cu drepturile de acces potrivite.
Documentele web recepționate de browser de la serverul web sunt reprezentate de
fișiere text scrise într-un limbaj special, numit HTML (HyperText Markup Language), limbaj care
constă într-un set de „înțelegeri” care definesc formatarea textului și cum va arăta acesta în
cadrul ferestrei navigatorului web. Marcajele, care definesc formatarea, controlează de
asemenea cum vor fi afișate legăturile către alte obiecte sau către grafice. În plus față de limbajul
de marcare, în documentul HTML pot fi inserate programe scrise în JavaScript și VBScript,
programe care vor fi interpretate doar de către browser-ul web în momentul în care documentul
web va fi încărcat și afișat.

2
2. HTTP (HyperText Transfer Protocol)

2.1 HyperText Transfer Protocol (HTTP) este metoda cea mai des utilizată pentru
accesarea informațiilor pe 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).

2.2 World Wide Web, abreviat WWW sau și www, numit scurt și web, care în engleză
înseamnă „pânză” (de păianjen); de multe ori este confundat cu rețea (net), este totalitatea
siturilor / documentelor și informaților de tip hipertext legate între ele, care pot fi accesate prin
rețeaua mondială de Internet (net = rețea). Documentele, care rezidă în diferite locații pe diverse
calculatoare server, pot fi regăsite cu ajutorul unui identificator univoc numit URL. Hipertextul
inclusiv imagini etc. este afișat cu un ajutorul unui program de navigare în web numit browser,
care descarcă paginile web de pe un server web și le afișează pe un terminal „client” la utilizator.
WWW este numai unul din numeroasele servicii și aplicații informatice disponibile pe
Internet. Alte servicii sunt de exemplu: afișarea de informații cu formă de text, imagini și sunete,
poșta electronică e-mail, transferul de fișiere de date și informații FTP, chat, aplicații video și
video on demand, servicii telefonie și telefonie cu imagine prin Internet de tip VoIP, posturi de
radio și televiziune prin Internet, e-commerce, sondări de opinie, răspândirea știrilor prin
metode RSS, toate genurile de grafică și muzică, lucrul pe un calculator de la distanță prin
Internet, grupuri de discuții pe diverse teme, sisteme de jocuri interactive, distribuție de
software ș.a.
Browser-ele actuale pot nu numai să afișeze pagini web, ci oferă și interfețe către celelalte
servicii Internet, având astfel un efect integrator (pentru toate serviciile e suficient un singur
browser). De aceea granițele dintre serviciul WWW și celelalte servicii din Internet nu sunt
întotdeauna clare.

2.3 File Transfer Protocol (FTP)


Protocolul pentru transfer de fișiere (sau FTP, din engl. File Transfer Protocol) este un
protocol (set de reguli) utilizat pentru accesul la fișiere aflate pe servere din rețele de
calculatoare particulare sau din Internet. FTP este utilizat începând de prin anul 1985 și
actualmente este foarte răspândit. Numeroase servere de FTP din toată lumea permit să se facă
o conectare la ele de oriunde din Internet, și ca fișierele plasate pe ele să fie apoi transferate
(încărcate sau descărcate). Web-ul nu aduce aici mari schimbări, ajută doar ca obținerea
fișierelor să se realizeze mai ușor, având o interfață mai prietenoasă decât aplicațiile
(programele) de FTP. Este posibil să se acceseze un fișier local prin adresa sa URL, ca și la o
pagină de Web, fie utilizând protocolul “file” (fișier), fie pur și simplu utilizând calea și numele
fișierului. Această abordare este similară utilizării protocolului FTP, dar nu necesită existența
unui server. Desigur funcționează numai pentru fișiere locale.

3
2.4 Versiuni de 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 cookie-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 routere. 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 trace-route la nivel aplicație.

2.5 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 browser-ul
trimite următoarea cerere la server:

4
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 redirecționează browser-ul 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
Browser-ul 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ÔÊ›Ä...
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

2.6 Metode

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

5
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

2.7 Coduri de răspuns HTTP

Codurile de stare al răspunsurilor 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 această clasa de răspuns/status. Aceste status-uri pot fi ignorate.
▪ 100 - continuă: Utilizatorul ar trebui să își continue cererea/acțiunea. Acest
răspuns provizoriu este folosit pentru a informa utilizatorul că partea inițială a
cererii a fost receptată și că deocamdată nu a fost refuzată de server. Utilizatorul
ar trebui să continue ș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ăspunzâ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 urmă
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/recepționată de la un server local.
▪ 204 - fără conținut: Server-ul a îndeplinit cererea si nu e nevoit sa întoarcă
răspunsul, dar ar dori sa răspundă printr-o informație recentă, gen meta.

6
▪ 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 - redirecționă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, primete răspunsul astfel încât utilizatorul/browser-ul să poată alege
modul dorit astfel încât redirecționarea 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
redirecționarea 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ă
redirecționeze 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 această
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 versiune anterioară a
specificațiilor deci nu mai este folosit, el fiind reținut.
▪ 307 - redirecționare temporară: Sursa cerută se află temporar la un diferit URI.
Din moment ce redirecționarea 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ăspunsurile 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 permanentă. Aceste răspunsuri sunt aplicabile
pentru orice fel de cerere. Browser-ele ar trebui să arate orice intrare cerută de utilizator.

7
▪ 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.
▪ 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 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ă: Server-ul 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.

8
3. BIBLIOGRAFIE

1. https://www.qreferat.com/referate/informatica/Serviciul-HTTP-Aplicatii-Web333.php
2. https://ro.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3. https://info12a.wordpress.com/2016/10/14/protocolul-http-www-world-wide-web-
ftp/

S-ar putea să vă placă și