Ministerul Educației al Republicii Moldova

Universitatea Tehnică a Moldovei

Facultatea Calculatoare, Informatica și Microelectronica
Departamentul Inginerie Software și Automatică

Raport
Lucrare de laborator nr.3
Disciplina: Programarea în rețea
Tema: Protocolul HTTP

A efectuat:
St. gr. TI-143 GainaCristin

A verificat:
Lect. asist. Ciudin S.

Chișinău 2017
Cuprins

1
.HTTP protocol................................................................................................................................3

1.1. Modul de funcționare...........................................................................................................3

1.2. Erori de HTTP......................................................................................................................3

1.3. Metode.................................................................................................................................8

1.4. Cîmpurile headerului...........................................................................................................9

2.HTML Agility Pack....................................................................................................................10

3.WebRequest și WebResponse....................................................................................................12

4.Dispatcher....................................................................................................................................14

5.Realizarea lucrării de laborator................................................................................................16

Concluzii.........................................................................................................................................17

Bibliografie.....................................................................................................................................18

Anexa A MainWindow..................................................................................................................19

Anexa B WebCrawling..................................................................................................................21

2
1.HTTP protocol

Hypertext Transfer Protocol (HTTP) 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).

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

1.2.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 continue cererea/acțiunea. Acest răspuns provizoriu este folosit pentru a

3
 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ă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 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/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.

4
 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.
5
 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.
6
 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.

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

Metodele disponibile sunt :

1. GET: este cea mai folosită metodă, fiind utilizată atunci când serverului i se cere o resursă.
2. 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.
3. PUT: metoda este folosită pentru a depune documente pe server, fiind inversul metodei GET.
4. POST: a fost proiectată pentru a trimite date de intrare către server.
5. DELETE: este opusul metodei PUT.
6. 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.
7. OPTIONS: este folosită pentru identificarea capacităților serverului Web, înainte de a face o
cerere.
8. CONNECT: este o metodă folosită în general de serverele intermediare.

8
 1.4.Cîmpurile headerului

Cîmpurile headerului este descrierea cererile și a răspunsurile mesajelor în

HTTP. Cîmpurile definesc parametri de procesare a unui tranfer HTTP.

Accept – Tipul de content care este acceptat de cerere.

Authorization – autentificarea pentru HTTP autentificare.

Connection – controlează opțiunile pentru conectarea conectă și lista de Hop-

By-Hop cîmpuri ale cererii.

Content-Length – lungimea corpului de cerere măsurată în octeți (8-bit).

Date – timpul cînd a fost expediat mesajul.

From – adresa de mail a utilizatorului care a format cererea.

Acestea nu sunt toate cîmpurile headerului.

9
2.HTML Agility Pack

HTML Agility Pack este un HTML parser agil, care construiește un DOM
citire/scriere și suportă XPATH sau XSLR. În cuvinte mai simple este o librarie .Net
care permite parsarea web fișierilor (HTML, PHP sau aspx).

Putem instala libraria HTML Agility Pack prin serviciul Nuget. Este posibil de
instalat prin Package Manager Console ”Install-Package HtmlAgilityPack”.

După ce am adăugat referința la librărie trebuie să adaugăm numele de spațiu

a librării care este ”using HtmlAgilityPack”.

Pentru a parsa un HTML fișier de pe un server (pentru a parsa un link din

internet) este posibil de utilizat clasa HtmlWeb.

HtmlWeb web = new HtmlWeb();

HtmlDocument document = web.Load(link);

După execuția codului de sus în variabila document se va afla tot html-ul.

Dacă avem deacum un document html care trebuie sa fie parsat e destul
următoarea:

HtmlDocument document = new HtmlDocument();

Document.Load(”directiva”);

Urmează un exemplu concret:

<html>  
<head>  
</head>  
<body>  
    <div id="div1">  
        <a href="div1-a1">Link 1 inside div1</a>  
        <a href="div1-a2">Link 2 inside div1</a>  
    </div>  
    <a href="a3">Link 3 outside all divs</a>      
10
    <div id="div2">  
        <a href="div2-a1">Link 1 inside div2</a>  
        <a href="div2-a2">Link 2 inside div2</a>  
    </div>  
</body>  
</html> 
Avem un document Html mai sus, de exemplu dorim tagurile ”a”, adica toate
hyperlinkurile.

HtmlDocument  document2 = new HtmlDocument();  
document2.Load(@"C:\Temp\sample.txt")  
HtmlNode[] nodes  = document2.DocumentNode.SelectNodes("//a").ToArray(); 

Specificarea unui div din document:

HtmlDocument  document2 = new HtmlDocument();  
document2.Load(@"C:\Temp\sample.txt")  
HtmlNode node = document2.DocumentNode.SelectNodes("//div[@id='div1']").First();

11
3.WebRequest și WebResponse

WebRequest este o clasă abstractă prin care se face cerere de la oare care
server prin intermediul URI. Clasa se află în System.Net ca și WebResponse.
WebResponse este o clasă în care se înscrie răspunsul de la cererea transmisă
anterior.

WebRequest are două constructoare:

WebRequest() – inițializează un nou exemplar al clasei WebRequest.

WebRequest(SerializationInfo,StreamingContext) – se inițializează pe baza unor

valori unicale.

Proprietățile clasei WebRequest sunt:

Method – întoarce sau setează metoda de cerere la server.

RequestUri – întoarce sau setează uri pe care se va face o cerere.

TimeOut – setează sau întoarce timpul de viața unei cereri.

Metodele clasei WebRequest sunt:

Abort() – întrerupe cererea.

Create(Uri) – inițializează o instanță WebRequest cu uri specificat.

CreateHttp(Uri) – inițializează o instanță HttpWebRequest cu uri specificat.

Exemplu:

using System;
using System.IO;
using System.Net;
using System.Text;

namespace Examples.System.Net
{
public class WebRequestGetExample

12
 {
public static void Main ()
{
//Crearea unei cereri spre url specificat
WebRequest request = WebRequest.Create ("http://www.google.com");
// Dacă severul necesită o verificare de validare
request.Credentials = CredentialCache.DefaultCredentials;
// Primirea răspunsuilui
HttpWebResponse response = (HttpWebResponse)request.GetResponse ();
// Vizualizarea stării răspunsuilui
Console.WriteLine (response.StatusDescription);
// Primește conținutul fișierului html
Stream dataStream = response.GetResponseStream ();
// Deschide un stream pentru acces mai rapid
StreamReader reader = new StreamReader (dataStream);
// Citirea conținutului
string responseFromServer = reader.ReadToEnd ();
// Afișarea rezultatelor
Console.WriteLine (responseFromServer);
//Eradierea strimului și a răspunsului
dataStream.Close ();
response.Close ();
}
}
}

13
4.Dispatcher

Dispecerul menține o coadă de elemente de lucru prioritar pentru un anumit fir. Atunci când un
Dispatcher este creat pe un fir, acesta devine singurul Dispecerul care poate fi asociat cu firul, chiar dacă
dispecerul este oprit.

Dacă încercați să obțineți CurrentDispatcher pentru firul de curent și un Dispecer nu este asociat
cu firul, va fi creat un Dispecer. Un Dispecerul este creat atunci când creați un DispatcherObject. Dacă
creați un Dispatcher pe un fir de fundal, asigurați-vă că pentru a închide expeditorul înainte de a ieși firul.
În cazul în care un Dispatcher este oprit, acesta nu poate fi repornit.

În WPF, un DispatcherObject poate fi accesat numai de către dispecerul este asociat. De exemplu,
un fir de fundal nu poate actualiza conținutul unui buton, care este asociat cu Dispecerul pe firul UI.
Pentru ca firul de fundal pentru a avea acces la proprietatea Conținutul butonului, firul de fond trebuie să
delege activitatea Dispecerului asociată cu firul UI. Acest lucru se realizează prin utilizarea fie Invoke sau
BeginInvoke. Invocare este sincron și asincron este BeginInvoke. Se adaugă operația la coada
dispecerului la DispatcherPriority specificat.

În cazul în care BeginInvoke este numit pe un Dispecer care a închis, proprietatea de stare a
DispatcherOperation returnat este setat la Abandonată. Toate metodele de pe Dispecer, cu excepția
DisableProcessing, sunt liber filetate. Obiectele care derivă din DispatcherObject au afinitate fir.

Obiectele care derivă din solidificabil sunt libere filetate atunci când sunt înghețate. Pentru mai
multe informații, consultați Obiecte solidificabil Prezentare generală.

Exemplu:
//Delegat care va indica la metoda ce se va invoca
public delegate void updater(string str);
// Metoda ce se executa de firele de execuție
public void method(object link)
{
try
{
WebRequest request = WebRequest.Create((string)link);
WebResponse response = request.GetResponse();
14
 this.richTextBox.Dispatcher.BeginInvoke(new updater(update), ((string)link + " ========
Status: " + ((HttpWebResponse)response).StatusCode.ToString()));
}
catch (Exception exc)
{
this.richTextBox.Dispatcher.BeginInvoke(new updater(update), ((string)link + " ========
Status: " + exc.Message));
}
}
//Metoda ce se invokă în timpul executiei unui fir pentru a seta un GUI element
public void update(string linkStatus)
{
this.richTextBox.AppendText(init+ "__ "+linkStatus);
this.richTextBox.AppendText("\n");
init++;
}

15
5.Realizarea lucrării de laborator

Fig. 1 – Rezultatul primit

Mai sus este reprezentat un textbox și un richtextbox. În textbox se introduce cheia după care
serviciul Google caută informație, iar richtextbox afișează adresele resurselor care conțin informația
despre cheia căutată. Pe lîngă adresele care sunt afișate este și starea serverului pe care rulează adresa
cutare.

După ce se introduce o cheie în textbox se tastează enter pentru ca programul să cere de la google
pagina cu rezultatele serviciului de cautare Google, pe care o parsează selectînd nodurile ce reprezint
referințe la adresele serverilor cu informația despre cheia cautată. Cererea la google pentru a primi pagina
rezultat se face cu ajutorul HtmlAgilityPack prin clasa HtmlWeb vezi Anexa B.

Html Aglity Pack automat face o cerere și primește un raspuns de la Uri specificat în contructor,
după care răspunsul este stocat în HtmlDocument, răspunsul este sub formă de Html document cu noduri
vezi capitolul HtmlAgilityPack. Apoi se trece la parsarea documentului raspuns, se selectează nodurile ce
reprezint referință apoi imediat sunt preluate valorile din atributele href. Așa cum valoarea în href
utilizează serviciul google este nevoie de cutat părțile de interogare la google pentru a primi url-ului
necesar care totuși se conține în valoarea hrefului.

După toate menționate se preiau adresele la servere și se cere stările serverilor cu ajutorul
claselor din spațiul de nume System.Net și anume clasele WebReequest și WebResponse.

16
Concluzii

Lucrarea de laborator numărul trei la programarea în rețea este realizată în limbajul C# utilizînd
mediul de dezvoltare Visual Studio 2015. Sarcina laboratorului este de a lucra cu protocolul HTTP și
anume de făcut un validator de adrese ”de verificat dacă serverele sunt valide”. 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). Sa accesat la serviciile google de
cautare, pentru a primi o pagină cu răspunsuri după căutare, din pagină sunt selectate toate nodurile ce
conțin adresele serverelor care urmează de controlat la validare. Cotrolul validării sa produs prin
WebRequest și WebResponse prin care sa făcut cereri și sa primit răspunsuri. Răspunsurile au fost stocate
într-o listă text care afișează adresele si validările. Problema listei este că un element ui creat într-un fir
este interzis să fie modificat în alt fir (fir de orice tip). Rezolvarea este de a folosi serviciul Dispatcherului
care permite de a invoka o metodă care poate modifica elemetui UI prin intermediul unui delegat vezi
Anexa A.

17
Bibliografie

1. Hyper text transfer protocol. [Resursa electronică].-regim de acces:

https://www.w3.org/Protocols/
2. Простым языком о HTTP. [Resursa electronică].-regim de acces:
https://habrahabr.ru/post/215117/
3. WebRequest Class . [Resursa electronică].-regim de acces:
https://msdn.microsoft.com/ru-ru/library/system.net.webrequest(v=vs.110).aspx
4. WebResponse Class. [Resursa electronică].-regim de acces:
https://msdn.microsoft.com/ru-ru/library/system.net.webresponse(v=vs.110).aspx
5. Dispatcher. [Resursa electronică].-regim de acces:
https://msdn.microsoft.com/ro-ro/library/system.windows.threading.dispatcher(v=vs.110).aspx
6. PR – programarea in retea. [Resursa electronică].-regim de acces:
http://moodle.ati.utm.md/course/view.php?id=90

18
Anexa A MainWindow
using System;
using System.Net;
using System.Threading;
using System.Windows;
using System.Windows.Input;
using WebCng;

namespace Lab_3_PR
{
public partial class MainWindow : Window
{
private static string urlToGoogleSearch = "https://www.google.com/search?num=100&q=";
private string checkLinks = "/url?q=";
public delegate void updater(string str);
int init = 0;
public MainWindow()
{
InitializeComponent();
}
private void textBox_KeyDown(object sender, KeyEventArgs e)
{
init = 0;
if (e.Key == Key.Enter)
{
richTextBox.Document.Blocks.Clear();
WebCrawling wc = new WebCrawling(urlToGoogleSearch, checkLinks, textBox.Text);
foreach (string link in wc.Links)
{
Thread th = new Thread(new ParameterizedThreadStart(method));
th.Start(link);
}
}
}
public void method(object link)
{
try
{
WebRequest request = WebRequest.Create((string)link);
WebResponse response = request.GetResponse();
this.richTextBox.Dispatcher.BeginInvoke(new updater(update), ((string)link + "
======== Status: " + ((HttpWebResponse)response).StatusCode.ToString()));

19
 }
catch (Exception exc)
{
this.richTextBox.Dispatcher.BeginInvoke(new updater(update), ((string)link + "
======== Status: " + exc.Message));
}
}
public void update(string linkStatus)
{
this.richTextBox.AppendText(init+ "__ "+linkStatus);
this.richTextBox.AppendText("\n");
init++;
}
}
}

20
Anexa B WebCrawling
using HtmlAgilityPack;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace WebCng
{
public class WebCrawling
{
private static string urlToGoogleSearch;
private List<string> links = new List<string>();
private string checkLinks;
public string URL { get { return urlToGoogleSearch; } set { urlToGoogleSearch =
value; } }
public string SubstractSufix { get { return checkLinks; } set { checkLinks=value; } }
public List<string> Links { get { return links; } set { links = value; } }
private HtmlWeb htmlFromWeb = new HtmlWeb();
HtmlDocument htmlFromUrl;
List<HtmlNode> htmlNodeWhatContainLinks;
public WebCrawling(string urlToGoogleSearch,string substractSufix, string searchKey)
{
this.URL = urlToGoogleSearch;
this.SubstractSufix = substractSufix;
htmlFromUrl = htmlFromWeb.Load(urlToGoogleSearch + searchKey);
htmlNodeWhatContainLinks =
htmlFromUrl.DocumentNode.SelectNodes("//h3[@class='r']//a").Where(x =>
x.Attributes["href"].Value.Contains(checkLinks)).ToList();
set(htmlNodeWhatContainLinks);
}
private void set(List<HtmlNode> htmlNodeWhatContainLinks)
{
List<string> linksTemp = new List<string>();
foreach (HtmlNode LinksNode in htmlNodeWhatContainLinks)
{
linksTemp.Add(cut(LinksNode.Attributes["href"].Value, checkLinks.Length));
}
Links = linksTemp;
}
private string cut(string strtocut, int checkLinksLength)

21
 {
return strtocut.Substring(checkLinksLength, strtocut.IndexOf("&amp;sa=U") - 7);
}
}
}

22