tematcp-ip.docx

21
Ichim Cezar Alexandru IB SCOALA POSTLICEALA „GHEORGHE MARZESCU” TEMA PROTOCOLUL HTTP

Upload: bradgauss

Post on 14-Feb-2016

215 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: tematcp-ip.docx

Ichim Cezar Alexandru IB

SCOALA POSTLICEALA „GHEORGHE MARZESCU”

TEMAPROTOCOLUL HTTP

Page 2: tematcp-ip.docx

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.

-cerere

Un mesaj de cerere HTTP

Page 3: tematcp-ip.docx

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

Apache, Netscape Enterprise Server, Sun Web Server, Windows NT Web Server, Stronghold.

-Proxy (intermediar)

Page 4: tematcp-ip.docx

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.

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:

Page 5: tematcp-ip.docx

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.

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

...

Page 6: tematcp-ip.docx

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

Page 7: tematcp-ip.docx

Serverul răspunde astfel:

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:

HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:32:43 GMT

Location: http://ro.wikipedia.org/wiki/pisici

Page 8: tematcp-ip.docx

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:

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

Page 9: tematcp-ip.docx

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

306 (nefolosit):

Page 10: tematcp-ip.docx

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:

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:

Page 11: tematcp-ip.docx

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:

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

Page 12: tematcp-ip.docx

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.

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.

Page 13: tematcp-ip.docx

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.

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

Page 14: tematcp-ip.docx

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

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

Page 15: tematcp-ip.docx

-DELETE

Cere ca serverul să şteargă resursa identificată de Request-URI.

-TRACE

Invocă o cerere de diagnosticare (trasaj).

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