TEMA: PRELUCRAREA

ERORILOR GENERATE DE
PROTOCOLUL HTTP

Autor: N.Pleșca, lector univ.

Conținut

■ Definirea noțiunilor
■ Erori ale protocolului HTTP (Hypertext Transfer Protocol)
■ Prelucrarea erorilor protocolului HTTP
Codurile stărilor răspunsurilor-HTTP
■ Codurile stărilor sunt transmise de server ca și răspuns la o anumită interogare făcută de client.
Răspunsurile serverului conțin coduri, alte detalii ale protocolului de transfer al hipertextului
(HTTP). Prima cifră a codului de stări definește una din cinci clase standarde cu răspunsuri.
Frazele din mesajele prezentate sunt tipice, dar dacă sunt prelucrate de dezvoltatori,
utilizatorilor le pot fi prezentate informații, alternative mai clare
■ Codurile de stări ale răspunsurilor HTTP indică dacă o anumită interogare a fost realizată cu
succes sau nu
■ De fiecare dată când se face o adresare la server clientul primește drept răspuns codul statutului/
stării
■ Aceste coduri se împart în 5 grupuri de bază și fiecare cod este format din 3 cifre. Grupul căruia îi
aparține codul poate fi ușor depistat după prima cifră:
– 1хх – răspunsuri informative
– 2хх – finalizare cu succes a interogării / răspuns cu succes
– 3хх – redirecționare
– 4хх – eroare pe partea clientului
– 5хх – eroare pe partea server
Documentația standard

■ Codurile de stări sunt definite în capitolul 10, din RFC 2616 (accesul la
document https://tools.ietf.org/html/rfc2616#section-10)
■ De asemenea, descrierea principalelor coduri de stări o găsiți aici
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status sau
https://www.restapitutorial.com/httpstatuscodes.html
 Descrierea unor erori HTTP
Sunt foarte multe erori posibile ce pot fi generate de protocolul HTTP, dar vom descrie unele, cele mai
des generate:
■ Erorile generate de client (400-499) – apar ca rezultat a interogării incorecte din partea clientului.
Chiar dacă aceste erori sunt generate de partea client, este necesar să li se acorde și lor suficientă
atenție și să fie cercetate toate variantele posibile de înlăturare ale lor pe partea server:
– 400 interogare incorectă – acest cod înseamnă că interogarea serverului s-a realizat incorect, posibil
a fost folosită o sintaxă incorectă (un url incorect sau au fost folosite simboluri-separatori incorecți)
– 404 nu a fost găsită resursa – această eroare înseamnă, că utilizatorul s-a adresat corect la server,
dar serverul nu a putut găsi resursa solicitată
■ Erori ale serverului (500-599) apar ca rezultat al activității serverului, atunci când el nu poate
prelucra cererea clientului și se ciocnește de anumite probleme interne
– 500 eroare internă a serverului – eroarea presupune, că cererea nu poate fi prelucrată de server,
dintr-un anumit motiv intern, necunoscut. Motivul cel mai frecvent – configurarea incorectă a
serverului (.htaccess incorect) sau se face o adresare la un pachet PHP neinstalat
– 503 serviciu indisponibil – acest cod ne sugerează, că serverul sau este suprasolicitat sau se afla la
deservire. Această eroare înseamnă că în viitorul apropiat serverul va deveni accesibil
 Ce se întâmplă cu erorile HTTP când
ele nu sunt prelucrate?
■ Presupun că tuturor măcar odată li s-a afișat așa o pagină, atunci când introduceați un URL
eronat sau un nume incorect de fișier
■ Iarăși – dacă e să analizăm reacția unui simplu utilizator – e o stare de stres  - adrenalină la
maximum
Alt exemplu – o prelucrare frumoasă a erorii
Soluția recomandată... prelucrarea acestor
erori
■ Există o soluție simplă recomandată în prelucrarea multor erori generate de
protocolul HTTP, precum 404, 500 ...și altele
■ Se recomandă reconfigurarea fișierului .htaccess – care trebuie să fie prezent în
oricare mapă a unui proiect PHP
■ De asemenea, vom crea și un fișier .php la care îl vom redirecta pe utilizator în
cazul unei erori HTTP (eu voi prelucra unele erori din grupurile 4хх și 5хх) și care
va prelucra toate aceste erori
■ În acest fișier voi crea un tablou ce va conține codurile erorilor și le voi pune în
corespondență unele texte pentru mesaje, corespunzător codului de stare și voi
face redirectarea utilizatorului cu PHP. Voi folosi aceași pagină la prelucrarea a
mai multor erori
Reînnoirea fișierului .htaccess
■ Trebuie reînnoit fișierul .htaccess, și să introducem datele referitoare la ce ar trebui să se întâmple dacă
se produce o eroare la accesarea unui fișier din mapa proiectului curent – serverul trebuie să știe cum să
reacționeze. Adăugăm în fișier și salvăm modificările:
ErrorDocument 400 /error_HTTP/error.php
ErrorDocument 403 /error_HTTP/error.php
ErrorDocument 404 /error_HTTP/error.php
ErrorDocument 405 /error_HTTP/error.php
ErrorDocument 408 /error_HTTP/error.php
ErrorDocument 500 /error_HTTP/error.php
ErrorDocument 502 /error_HTTP/error.php
ErrorDocument 504 /error_HTTP/error.php
■ În cazul nostru, noi vom redirecționa toate erorile generate de protocolul HTTP în fișierul responsabil de
prelucrarea erorilor error.php (care se află în mapa error_HTTP) sau acest fișier poate fi plasat în mapa
rădăcină localhost și atunci în toate mapele din localhost, în fișierele .htaccess vom redirecta erorile la
- /error.php
Ce scriem în fișierul error.php?
■ Pe lângă conținutul static care deja era (imagini și text de consolare și
link - index.php) în el voi crea și un mic scriptuleț care va redirecționa
textul erorii într-un fișier suplimentar de loguri, astfel încât acest text să
nu-l vada utilizatorul, dar la necesitate, să-l vadă administratorul
aplicației
■ Codul e pe slide-ul următor...
<?php
$fileName = "d:/loguri/log_http_errors.txt";
$status = $_SERVER['REDIRECT_STATUS'];
$codes = array(400 => array('400 Bad Request', 'The request cannot be fulfilled due to bad syntax.'),
403 => array('403 Forbidden', 'The server has refused to fulfil your request.'),
404 => array('404 Not Found', 'The page you requested was not found on this server.'),
405 => array('405 Method Not Allowed', 'The method specified in the request is not allowed for the specified resource.'),
408 => array('408 Request Timeout', 'Your browser failed to send a request in the time allowed by the server.'),
500 => array('500 Internal Server Error', 'The request was unsuccessful due to an unexpected condition encountered by the server.'),
502 => array('502 Bad Gateway', 'The server received an invalid response while trying to carry out the request.'),
504 => array('504 Gateway Timeout', 'The upstream server failed to send a request in the time allowed by the server.’), );
$title = $codes[$status][0];
$message = $codes[$status][1];
if ($title == false || strlen($status) != 3) { $message = 'Please supply a valid HTTP status code.’; }
$fieldsSeparator = "\t\t";
if (!file_exists($fileName))
{ $fileO=fopen($fileName,"w") or die("Eroare a protocolului!");
$logLine = "Data ora".$fieldsSeparator.$fieldsSeparator."IP user".$fieldsSeparator.$fieldsSeparator."Mesaj";
fwrite($fileO, $logLine."\r\n");
fclose($fileO); }
$logLine =date("d/m/y H:i:s").$fieldsSeparator.$_SERVER['REMOTE_ADDR'].$fieldsSeparator."Detectat: ".$title." - ".$message;
$fileO=fopen($fileName,"a") or die("Eroare!");
fwrite($fileO, $logLine."\r\n");
fclose($fileO);
?>
Acum ce se va întâmpla dacă voi greși la
introducerea denumirii fișierului (URL-ului)
■ Utilizatorului îi afișez...
Acum ce se va întâmpla dacă voi greși la
introducerea denumirii fișierului (URL-ului)
■ Iar în fișierul de loguri, pentru administrator, se va insera o înregistrare cu textul erorii...
Concluzii

■ Prelucrați, după posibilități, cât mai multe erori, inclusiv cele generate de
protocolul HTTP
■ Rețieneți, că aceste erori tot îl deranjează pe utilizator
■ Administratorului îi puteți adăuga o funcționalitate suplimentară, ca el să
aibă posibilitatea vizualizării fișierelor cu erori
 Sarcină pentru testul nr. 2
Vom continua ”fortificarea” aplicației-problemă începută la testul 1...
■ Pentru pagină ce conține un formular care are destinația colectării emailurilor utilizatorilor care doresc să se aboneze la
noutățile site-ului. Va amintesc - formularul constă dintr-un element de intrare și un buton pentru expedierea mailului
pentru salvare
■ Toate emailurile se vor păstra într-o BD, în tabelul «emails» care are structura datelor id_mail(AI) , email(string(25)),
data(date)
■ Administratorul folosește lista emailurilor colectate pentru a distribui diferite informații. El poate expedia informații
tuturor abonaților sau selectiv. Pentru a avea acces la funcționalități administratorul, la intrare, trebuie să se autentifice.
Toate datele despre conturile administratorului sunt stocate în tabelul users (id_user(AI), login(string(15)),
password(string(15))).
Sarcină:
1. Creați pentru aplicația realizată, cu două tipuri de utilizatori - user simplu și admin, fișierele de loguri și cele
pentru protocolarea erorilor, cele pe care le considerați necesare...și pagina care poate reacționa la situațiile
stresante pentru utilizator
2. Explicați necesitatea creării acestor fișiere și a paginii de refugiu (într-un fișier word)
3. Soluția problemei + fisierul Word, le atașați pe Moodle, imediat după această tema, sub formă de arhivă, până
sâmbăta, 19.11.22, ora 24:00.
PS: Persoanele care nu realizează sarcina propusă mai sus – vin pe 30.11.22, să scrie testul 2