2.4 Flux de Date În Procesul Response-Request

Curs: Advanced PHP programming - Building Web Applications
Modul: Programarea web

Unitate: Flux de date în procesul Response/Request
Principiile de bază ale funcționării protocolului HTTP
Pentru a înțelege cum sunt transferate datele în timpul procesului

Reponse/Request, de la o pagină web la alta, de la o aplicație la alta
sau mai simplu spus, de pe web la o aplicație și invers, trebuie să știm
cum funcționează protocolul HTTP.
HTTP (Hyper Text Transfer Protocol) este un protocol al cărui rol este
să coordoneze cererile și răspunsurile de pe Internet-intranet. Aceste
cereri sunt stabilite de obicei de către diverși clienți (diverse forme de
aplicații), în timp ce serverele web se ocupă de răspunsuri.
Indiferent de tip, în acest proces, clientul este denumit User Agent, în

timp ce serverul este denumit origin server.
Când există o cerere, User Agent expediază serverului informații

despre ce tip de MIME (Multimedia Internet Mail Extensions – diferite
tipuri de documente, HTML, imagini, arhive...) poate accepta, de ce
versiune a protocolului HTTP are nevoie, despre ce versiune de User
Agent este vorba, de ce layout de cod este nevoie, referințele (pagina
de pe care a venit cererea, dacă aceasta există) informațiile cookie,
statusul cache al User Agent (în cazul în care pagina se află în cache-ul
de client)...
Cererea conține metoda HTTP, sau o formă pe care serverul web

trebuie să o respecte atunci când procesează cererea și când
manipulează resursele. Metoda poate fi caracterizată mai bine ca o
comandă simplă. Dacă, de exemplu, vom tasta în browser
www.siteulmeu.com/index.html, am putea fi siguri că undeva în
cererea noastră va fi o linie:
GET /index.html HTTP/1.1
Precum și linia:
host: www.siteulmeu.com
unde GET este numele metodei, /index.html este adresa domeniului,
© Copyright Link group 1 / 12

HTTP/1.1 este versiunea de protocol și host-ul: www.siteulmeu.com

este numele de domeniu de top al acestui site.
Pe baza acestor informații, serverul web formează un răspuns și îl

expediază clientului.
GET nu este singura metodă. Putem folosi de asemenea metodele

HEAD și POST. Pe lângă acestea, mai există încă câteva metode de
Request: PUT, DELETE, OPTIONS, CONNECT...
Când o cerere este formată într-un anumit mod, serverul formează un

răspuns și îl trimite înapoi, la cel care a expediat cererea (serverul, în
orice moment, știe care este adresa IP și portul la care răspunsul
trebuie trimis).
Răspunsul serverului conține statusul - 200, dacă totul este în regulă

sau multe alte numere de erori, dacă nu este în regulă. Cele mai
întâlnite numere sunt 404 (pagina cerută nu există) sau 500 (eroare în
aplicația web). De fapt, statusurile afișate prin numere se împart în
câteva categorii: 1xx pentru informații, 2xx toate tipurile de
abstractizări reușite, 3xx redirecționări, 4xx erori de client, 5xx erori
de server.
Pe lângă status, răspunsul are de obicei un header și un corp de

document.
Întregul proces arată în felul următor:
Clientul introduce adresa:
http://www.siteulmeu.com/index.html
...User Agent deschide un socket prin portul 80 și trimite cererea prin

el:
GET /path/file.html HTTP/1.0

Host: www.siteulmeu.com
După acceptarea cererii, serverul trimite următorul răspuns către

același port, prin același socket:
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 500
<html>
<body>
Acesta este un răspuns de server:
</body>
</html>
După toate acestea, este complet irelevant ce va face User Agent cu

răspunsul primit. Dacă este vorba de un browser web, acest răspuns
va fi parsat și emis clientului, dar aplicația poate face și alte lucruri. De
exemplu, Crawler (browser web), sistem de analiză a traficului pe
Internet...
Pe baza acestor informații, putem vedea că prin HTTP, lucrurile

funcționează foarte ușor.
Transportul de stări
Am văzut cum sunt expediate datele în timpul procesului

Request/Response. Clientul solicită anumite date de la server, care
apoi trimite un răspuns înapoi. Problema este că serverul nu este
capabil să recunoască cine i-a trimis cererea. El trimite pur și simplu
un răspuns înapoi, pe baza unei adrese IP și a unui port, și cam asta e

tot. Asta înseamnă că nu este capabil să vadă, de exemplu, dacă

utilizatorul mai este pe pagina de pe care a fost emisă cererea. Din
acest motiv, se spune despre protocolul HTTP că este Stateless (nu
stochează starea utilizatorului).
O astfel de manieră de operare este logică, având în vedere că sunt

executate două tipuri diferite de sarcini, pe două locații diferite (client
și server), care nu au legătură una cu cealaltă. Acest lucru ridică
anumite probleme, fiindcă trebuie să utilizăm anumite metode pentru
expedierea datelor referitoare la stare, pe parcursul procesului
Response/Request.
Există trei modalități diferite de manipulare a stării într-o aplicație web

PHP. În această lecție, vom explica modul de funcționare a acestora,
iar în următoarea vom vedea cum se utilizează practic.
GET/POST
Aceste două metode sunt menționate în contextul cererii (Request)

HTTP.
GET
GET este metoda principală și cea mai obișnuită de obținere a unui

răspuns de server. Aceasta atașează adresa cu răspunsul dorit. Dar, în
afară de adresă, cererea mai poate conține și anumiți parametrii pe
care serverul este capabil să-i diferențieze, iar programatorul îi poate
utiliza în codul de server.
Parametrii trimiși prin metoda GET nu prezintă deloc siguranță. Aceștia

sunt lipsiți de protecție, fiindcă sunt emiși prin Query string (string
care reprezintă întreaga adresă a paginii). Din acest motiv, parametrii
GET sunt adesea criptați.

De ex.
www.siteulmeu.com/index.php?id=098f6bcd4621d373cade4e832627b
4f6. În acest fel, nu sunt expediate nici un fel de informații vitale
pentru securitate. Codul este o reprezentare codată a unui segment de
date sursă, unde sunt păstrate anumite informații. Și numai de acolo
pot fi făcute verificările serioase (precum, verificările de utilizator).
Chiar dacă se procedează astfel, fluxul de date vitale prin stringul
Query este nesigură și nerecomandată. În plus, poate să transfere o
cantitate enormă de informații.
Asta nu înseamnă că expedierea informațiilor prin stringul Query

trebuie evitată și atunci când avem de-a face cu informații fără context
de securitate.
De exemplu, www.siteulmeu.com/index.php?produs=15. În acest caz,

trimiterea datelor printr-un Query este bună, fiindcă un utilizator rău
intenționat nu poate dăuna aplicației, prin introducerea unui număr de
produs greșit (cu excepția faptului că există un produs pe care nu-l
vrea), iar linkul este lizibil și funcțional. Desigur, asigurați-vă că orice
abatere de la scenariul dorit este procesată în codul de server.
Una dintre formele de manipulare a stringului Query este prin copierea

URL-ului.
Copierea URL-ului funcționează prin setarea anumitor convenții pe

serverul web, pe care web-ul le va observa și va forma răspunsuri pe
baza lor. Aceste convenții sunt intermediare între ierarhia actuală a
fișierelor de pe serverul web și ceea ce este cerut de către utilizator în
query (interogare).
Exemplul anterior:
www.siteulmeu.com/index.php?produs=15 poate fi parsat în:
www.siteulmeu.com/produse/15, dacă specificăm serverului să trateze

partea de adresă „produse″ ca index.php?produs= , în timp ce partea
cu numărul (în acest caz: 15), ca cea de-a doua parte a adresei.

În acest fel, este posibilă o manipulare puternică a numelor de adrese

(URI-uri). De ex., toate extensiile .php pot fi afișate fără probleme pe
server, ca .aspx sau ca orice alt tip de extensii, în timp ce aplicația php
va rula fără probleme pe server.
Copierea URL-ului, ca modul, ar trebui activată separat în serverul

Apache și adesea este exclusă sau interzisă, în cazul în care nu utilizați
propriul server pentru host.
Acest lucru este cauzat de faptul că modulul poate provoca probleme,

dacă nu este manipulat cu grijă. De exemplu, se poate întâmpla să
blocați folderul în care lucrați și să nu-l mai puteți utiliza după aceea,
fapt ce poate reprezenta o problemă majoră dacă utilizați un sistem de
hosting, remote și automat.
POST
Metoda POST funcționează oarecum diferit față de metoda GET și este

puțin mai sigură. Când sunt trimise cereri la server, dacă cererea
apelează această metodă, în corpul cererii va apărea un set de date
serializate, pe care serverul sau aplicația de server le poate prelua
pentru procesare. Informația expediată în acest mod nu este vizibilă
cu ochiul liber. Prin revizuirea codului HTML al paginii, putem găsi
toate datele transportate.
Acest mod de transportare a datelor se utilizează de obicei pentru

aplicații ale căror controale (forme) sunt procesate și nu sunt suficient
de bune pentru promovarea unei pagini web anume, fiindcă nu poate
fi expediată numai adresa paginii web, deoarece nu va returna nici un
rezultat fără datele cerute. Pentru a expedia aceste date, avem nevoie
de o formă pentru a le serializa și trimite.
Cookie

Cele două metode menționate mai sus, deși nu sunt imposibile, nu

reprezintă tocmai un model adecvat de stocare în siguranță a stărilor
în procesul Request/Response. Informațiile circulă de obicei prin fața
utilizatorilor, într-o formă necriptată, fapt ce face ca aceste metode să
fie nesigure pentru orice informație care trebuie securizată și ascunsă.
Spre deosebire de acestea, cookie reprezintă o modalitate mai bună

de păstrare a integrității informațiilor în timpul procesului. De fapt, nu
participă în mod activ în proces, dar în schimb stochează date pe
calculatorul client (în sensul că nu va fi vizibil, dar odată activat,
cookie face parte din toate cererile direcționate spre server, până când
expiră). Această abordare permite ca datele să fie stocate pe termen
nelimitat, iar manipularea lor să fie efectuată doar atunci când este
necesar, reducând astfel suprasolicitarea fluxului de date.
Cookie-urile se află pe calculatorul client, astfel încât au o șansă mai

mare să fie șterse sau furate. Cu toate acestea, reprezintă o
modalitate excelentă pentru server, în timpul fiecărei cereri, în cazul în
care dorește să știe cu ce client comunică.
Trebuie menționat faptul că cookie-urile (precum sesiunile, care vor fi

menționate mai jos) nu sunt recomandate pentru stocarea unei
cantități mari de date. Acestea sunt blocuri mici de date (nu sunt mai
mari de 4k per site) care se folosesc pentru a stoca doar informațiile
de bază care leagă clientul de server. De exemplu, ID-ul utilizatorului
ale cărui informații aflate sub acest număr vor fi extrase dintr-o sursă
de date de pe server.
Sessions (sesiunile)
În cele din urmă, cea mai populară metodă de stocare a stărilor pe un

server web este sesiunea. În general, sesiunea funcționează în același
fel cu cookie, dar presupune faptul că veți stoca date de client pe
server.

De exemplu, când un client cere ca o sesiune să fie deschisă pentru

prima dată, este generat un număr unic (PHPSESSID) pe server, care
în viitor va reprezenta clientul respectiv în lista de sesiuni. Acest ID
este memorat într-un fișier de server (Session Store File) și va fi
expediat clientului. Apoi, aplicația de client formează un cookie cu
acest număr, iar mai apoi, la fiecare cerere îl va expedia serverului,
astfel încât acesta să poată identifica sesiunea și din ea să expedieze
informația cerută.
Deși sesiunile operează cu ajutorul cookie-urilor, nu trebuie să le aveți
pe acestea din urmă pentru a putea manipula sesiunile. Sesiunile pot fi
obținute manual, prin expedierea ID-ului sesiunii în stringul Query,
către server:
http://www.siteulmeu.com/index.php?PSESSID=be20081806199800da
22e24081964000
În ceea ce privește informațiile care trebuie păstrate în sesiuni, la fel

ca în cazul celorlalte sisteme descrise, rămâne valabilă recomandarea
că nu trebuie stocate informațiile concrete, ci mai degrabă numai
identificatorii prin care putem obține informațiile concrete dintr-una
dintre sursele de date de pe server.
Sesiunile sunt destul de sigure, dar nu indestructibile (de ex., prin

tehnica de trimitere a ID-ului sesiunii printr-un string Qeury, se poate
obține sesiunea altcuiva, dacă se ghicește (Session Hijack)).
De reținut din lecție:
1. Protocolul HTTP este Stateless (nu poate stoca starea unui

utilizator).
2. Prin metode alternative (GET/POST, Cookie, Session), se poate

stoca starea în procesul Request/Response.

3. GET/POST – nesigură, Cookie – mai sigură, Session – cea mai

sigură.
4. GET/POST – datele sunt transferate de fiecare dată de la client la

server.
5. Cookie – data se află la client.
6. Session – data se află pe server.
7. Prin default, sesiunea funcționează cu ajutorul cookie-urilor, dar

poate fi manipulată și manual prin utilizarea codului PHPSISSID.
8. Există mai multe metode pe care o cerere le conține în protocolul

HTTP (POST, GET, HEAD, DELETE...).

APHP_04 - Advanced PHP Programming

1. Sesiunile:
a) Pot funcționa fără cookie-uri
b) Nu pot funcționa fără cookie-uri
c) Pot funcționa fără cookie-uri, dacă ID-ul lor este expediat
manual
d) Nu au nicio legătură cu cookie-urile
2. Cookie este:
a) Virus
b) Worm
c) Bloc de informații schimbate între un server web și client
d) O informație de pe server care este disponibilă clientului,
cu ajutorul unui ID
3. Cookie este stocat:
a) Pe calculatorul server
b) Pe calculatorul client
c) În baza de date
d) Nu este stocat nicăieri, există doar în timpul procesului
response/request
4. Sesiunea (session) este stocată:
a) Pe calculatorul server
b) Pe calculatorul client
c) În baza de date
d) Nu este stocată nicăieri, există doar în timpul procesului
response/request
5. Care metodă de transfer de date este cea mai sigură?
a) Session
b) POST

c) GET
d) Cookie
6. În ce parte a procesului request/response putem găsi linia:
a) Request
b) Response
c) GET
d) POST
7. Ca răspuns la o cerere validă de client, serverul returnează
întodeauna:
a) Status și conținut
b) Numai status
c) Numai conținut
d) Status

1. Sesiunile:
c
2. Cookie este:
c
3. Cookie este stocat:
b
4. Sesiunea (session) este stocată:
a
5. Care metodă de transfer de date este cea mai sigură?
a
6. În ce parte a procesului request/response putem găsi linia:
a
7. Ca răspuns la o cerere validă de client, serverul returnează
întodeauna:
d

2.4 Flux de Date În Procesul Response-Request

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2.4 Flux de Date În Procesul Response-Request

Încărcat de

Drepturi de autor:

Formate disponibile

Curs: Advanced PHP programming - Building Web Applications

Modul: Programarea web

Principiile de bază ale funcționării protocolului HTTP

Pentru a înțelege cum sunt transferate datele în timpul procesului

Indiferent de tip, în acest proces, clientul este denumit User Agent, în

Când există o cerere, User Agent expediază serverului informații

Cererea conține metoda HTTP, sau o formă pe care serverul web

GET /index.html HTTP/1.1

unde GET este numele metodei, /index.html este adresa domeniului,

© Copyright Link group 1 / 12

HTTP/1.1 este versiunea de protocol și host-ul: www.siteulmeu.com

Pe baza acestor informații, serverul web formează un răspuns și îl

GET nu este singura metodă. Putem folosi de asemenea metodele

Când o cerere este formată într-un anumit mod, serverul formează un

Răspunsul serverului conține statusul - 200, dacă totul este în regulă

Pe lângă status, răspunsul are de obicei un header și un corp de

Clientul introduce adresa:

...User Agent deschide un socket prin portul 80 și trimite cererea prin

GET /path/file.html HTTP/1.0

După acceptarea cererii, serverul trimite următorul răspuns către

© Copyright Link group 2 / 12

același port, prin același socket:

Acesta este un răspuns de server:

După toate acestea, este complet irelevant ce va face User Agent cu

Pe baza acestor informații, putem vedea că prin HTTP, lucrurile

Am văzut cum sunt expediate datele în timpul procesului

© Copyright Link group 3 / 12

tot. Asta înseamnă că nu este capabil să vadă, de exemplu, dacă

O astfel de manieră de operare este logică, având în vedere că sunt

Există trei modalități diferite de manipulare a stării într-o aplicație web

Aceste două metode sunt menționate în contextul cererii (Request)

GET este metoda principală și cea mai obișnuită de obținere a unui

Parametrii trimiși prin metoda GET nu prezintă deloc siguranță. Aceștia

© Copyright Link group 4 / 12

Asta nu înseamnă că expedierea informațiilor prin stringul Query

De exemplu, www.siteulmeu.com/index.php?produs=15. În acest caz,

Una dintre formele de manipulare a stringului Query este prin copierea

Copierea URL-ului funcționează prin setarea anumitor convenții pe

www.siteulmeu.com/index.php?produs=15 poate fi parsat în:

www.siteulmeu.com/produse/15, dacă specificăm serverului să trateze

© Copyright Link group 5 / 12

În acest fel, este posibilă o manipulare puternică a numelor de adrese

Copierea URL-ului, ca modul, ar trebui activată separat în serverul

Acest lucru este cauzat de faptul că modulul poate provoca probleme,

Metoda POST funcționează oarecum diferit față de metoda GET și este

Acest mod de transportare a datelor se utilizează de obicei pentru

© Copyright Link group 6 / 12

Cele două metode menționate mai sus, deși nu sunt imposibile, nu

Spre deosebire de acestea, cookie reprezintă o modalitate mai bună

Cookie-urile se află pe calculatorul client, astfel încât au o șansă mai

Trebuie menționat faptul că cookie-urile (precum sesiunile, care vor fi

În cele din urmă, cea mai populară metodă de stocare a stărilor pe un

© Copyright Link group 7 / 12

De exemplu, când un client cere ca o sesiune să fie deschisă pentru

În ceea ce privește informațiile care trebuie păstrate în sesiuni, la fel

Sesiunile sunt destul de sigure, dar nu indestructibile (de ex., prin

De reținut din lecție:

1. Protocolul HTTP este Stateless (nu poate stoca starea unui

2. Prin metode alternative (GET/POST, Cookie, Session), se poate

© Copyright Link group 8 / 12

3. GET/POST – nesigură, Cookie – mai sigură, Session – cea mai

4. GET/POST – datele sunt transferate de fiecare dată de la client la

5. Cookie – data se află la client.

6. Session – data se află pe server.