Linguaggi e Tecnologie Per Il Web

Linguaggi e tecnologie per il Web
Attilio Nicola Nocera

11 aprile 2015
Indice
1 Introduzione
1.1 Cosa mi appresto ad imparare? . . . . . . . . . . . . . . . . . . .
1.2 Cosa sar in grado di realizzare dopo aver studiato? . . . . . . .
4
4
4
2 Architettura del WWW browser, Unicode, URL

2.1 Ipertesto . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Paul Otlet . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Vannevar Bush . . . . . . . . . . . . . . . . . . . .
2.1.3 Ted Nelson . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Tim Berners Lee e le origini del World Wide Web
2.1.5 Architettura del WWW . . . . . . . . . . . . . . .
2.1.6 WorldWideWeb Consortium . . . . . . . . . . . . .
Attori del W3C . . . . . . . . . . . . . . . . . . . .
Iter delle specifiche W3C . . . . . . . . . . . . . .
2.1.7 Web Browser . . . . . . . . . . . . . . . . . . . . .
Architettura di un Web browser . . . . . . . . . .
Architettura di Mozilla Firefox . . . . . . . . . . .
Proxy based browser . . . . . . . . . . . . . . . . .
Compatibilit dei browser . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
8
10
12
12
13
14
16
16
19
20
21
3 HTTP
3.1 Introduzione . . . . . . . . . . . . . . .
3.2 Principio di funzionamento di HTTP .
3.3 Versioni di HTTP . . . . . . . . . . .
3.4 Entit . . . . . . . . . . . . . . . . . .
3.5 Struttura dei messaggi HTTP . . . . .
3.5.1 Backus - Naur Form . . . . . .
BNF rules . . . . . . . . . . . .
Esempio di BNF . . . . . . . .
3.5.2 HTTP: tipologia messaggi . . .
3.5.3 HTTP: Header . . . . . . . . .
3.5.4 HTTP: MIME . . . . . . . . .
3.5.5 HTTP: Body . . . . . . . . . .
3.5.6 HTTP: Message Length . . . .
3.5.7 HTTP: Header generici . . . .
3.5.8 HTTP: Header field dellentit
3.5.9 HTTP: Request message . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
23
23
24
24
24
25
26
26
26
28
28
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Request - Line . . . . . . . . .
Metodi . . . . . . . . . . . . . .
Header . . . . . . . . . . . . . .
3.5.10 HTTP: Response message . . .
Status code . . . . . . . . . . .
Reason phrase . . . . . . . . .
Header . . . . . . . . . . . . . .
3.5.11 HTTP: Authentication . . . . .
Basic access authentication . .
Digest access authentication . .
3.6 Connessione HTTP . . . . . . . . . . .
3.6.1 HTTP 1.0 . . . . . . . . . . . .
3.6.2 HTTP 1.1 . . . . . . . . . . . .
Pipelining . . . . . . . . . . . .
3.7 Gestione delle sessioni . . . . . . . . .
3.7.1 Cookie . . . . . . . . . . . . . .
Architettura di un cookie . . .
Alternative ai cookie . . . . . .
Third - Party Cookies . . . . .
3.8 Proxy server . . . . . . . . . . . . . . .
3.8.1 Reverse proxy . . . . . . . . . .
3.9 Caching . . . . . . . . . . . . . . . . .
3.9.1 Convalida della risorsa in cache
Convalidatori (validators) . . .
3.10 Modelli di sicurezza . . . . . . . . . .
TLS . . . . . . . . . . . . . . .
4 Apache HTTP Server
4.1 Installazione nei S.O. Windows . . .
4.2 Installazione nei S.O. UNIX-like . . .
4.3 Avvio del server . . . . . . . . . . . .
4.4 Avvio come servizio di sistema . . .
4.5 Configurazione . . . . . . . . . . . .
4.6 Direttive di base . . . . . . . . . . .
4.7 Moduli . . . . . . . . . . . . . . . . .
4.8 Server-side include . . . . . . . . . .
4.9 Direttiva IfModule . . . . . . . . . .
4.10 Log degli errori . . . . . . . . . . . .
4.11 Log degli accessi . . . . . . . . . . .
4.12 Direttive per le directory . . . . . . .
4.13 Direttiva per i file . . . . . . . . . .
4.14 Ridirezione . . . . . . . . . . . . . .
4.15 Alias . . . . . . . . . . . . . . . . . .
4.16 Messaggi derrore personalizzati . . .
4.17 Directory personali degli utenti . . .
4.18 Direttiva Include . . . . . . . . . . .
4.19 Controllo di accesso:elementi di base
4.20 File.htaccess . . . . . . . . . . . . . .
4.21 Caching . . . . . . . . . . . . . . . .
4.22 Virtual host: introduzione . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
32
34
34
35
36
36
36
37
37
37
38
38
39
39
39
40
41
41
42
42
43
43
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
46
46
47
50
50
51
52
53
53
54
54
55
56
57
57
58
58
59
59
60
61
62
4.23
4.24
4.25
4.26
4.27
4.28
4.22.1 IP-based virtual hosting . .

4.22.2 Name-based virtual hosting
Multi-processing modules . . . . .
Prefork MPM . . . . . . . . . . . .
Worker MPM . . . . . . . . . . . .
Event MPM . . . . . . . . . . . . .
XAMPP . . . . . . . . . . . . . . .
Riferimenti . . . . . . . . . . . . .
5 Nginx
5.1 Nginx
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
63
63
64
64
64
65
65
vs. Apache . . . . . . . . . . . . . . . . . . . .
Installazione in ambiente Windows . . . . . .
Installazione in ambiente UNIX-like . . . . .
Avvio, arresto, riavvio (ambiente UNIX-like)
Test . . . . . . . . . . . . . . . . . . . . . . .
File di configurazione nginx.conf . . . . . . .
Esempio di virtual hosting . . . . . . . . . . .
Ngynx come proxy server . . . . . . . . . . .
Considerazioni prestazionali . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
66
66
66
66
66
67
67
67
6 Sistemi informativi distribuiti: layer, tier, metodologie di progetto

6.1 Architettura di un sistema informativo distribuito . . . . . . . .
6.2 Metodologie di progetto . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Top - down . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Bottom - up . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Confronto tra Top - down e Bottom - up . . . . . . . . . .
6.3 Componenti del sistema, layer e connessioni . . . . . . . . . . . .
6.3.1 Layer e tier . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura 1-tier . . . . . . . . . . . . . . . . . . . . . .
Architettura N-tier . . . . . . . . . . . . . . . . . . . . . .
Comunicazione tra moduli . . . . . . . . . . . . . . . . . .
67
68
68
68
69
69
70
71
71
72
72
74
74
7 Middleware
74
7.1 RPC - Remote Procedure Call . . . . . . . . . . . . . . . . . . . 75
7.1.1 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Binding dinamico . . . . . . . . . . . . . . . . . . . . . . . 77
8 SOA e Web Service
78
9 Web Service: tecnologie
78
10 Web Service: composizione, BPEL, ESB
78
11 Linguaggi di schema e DTD
78
12 REST, Web 2.0
78
13 Cloud Computing
78
14 Information retrieval con Apache Lucene
78
15 WebSocket (RFC 6455)
78
16 Online marketplaces
78
17 Sponsored Search
78
18 Web of Things
78
19 Hadoop
78
Bibliografia
79
Introduzione
1.1
Cosa mi appresto ad imparare?
Principali tecnologie del Web e sistemi informativi orientati al Web;

principali classi di applicazioni, incluse quelle orientate ai servizi e quelle
emergenti;
aspetti teorici e pratici della ricerca di informazioni non strutturate sul
Web e aspetti precipui delle transazioni sul Web;
progettazione e realizzazione di Web application database-driven;
web service, cloud computing e Web of Things, con relative basi teoriche
e applicative per affrontare questi nuovi paradigmi.
1.2
Cosa sar in grado di realizzare dopo aver studiato?
Sar in grado di utilizzare le principali tecnologie Web;

sar in grado di realizzare semplici Web application e Web service.
2
2.1
Architettura del WWW browser, Unicode, URL

Ipertesto
Lipertesto una collezione di documenti connessi reciprocamente da collegamenti ipertestuali (hyperlink). Pi specificatamente un ipertesto consiste essenzialmente in un testo non lineare e non sequenziale, formato da documenti a loro volta composti da una collezione di nodi (frammenti di testo o altri
media) connessi da collegamenti.
Lorigine del termine scissa dal concepimento del WorldWideWeb e, semanticamente, ha acquisito lattuale significato mediante differenti contributi
forniti in epoche diverse.
2.1.1
Paul Otlet
Paul Otlet1 nel 1910, in occasione dellEsposizione mondiale di Bruxelles, assieme

ad Henri La Fontaine cre uninstallazione chiamata Mundaneum, che avrebbe
dovuto rappresentare una cittadella dellintelletto, il centro pulsante di una citt
utopica che ospitasse la societ delle nazioni mondiali. Nel 1919, Otlet convinse
il Re Alberto del Belgio a fornire una nuova sede al Mundaneum, in 150 stanze
del Palais du Cinquantenaire, allinterno della quale riun il suo vasto edificio
documentario, con pi di 12 milioni di schede e documenti.
Figura 1: Paul Otlet

Otlet era preoccupato dal problema della fruibilit del database stesso. Verso la fine degli anni 30, egli cominci a pensare ai vari modi in cui le nuove
tecnologie dellepoca (radio, cinema, microfilm e televisione) potessero essere
1 (Bruxelles 1868 - 1944) fu uno dei maggiori esperti moderni di bibliografia. Nel 1895
fond, insieme a Henri La Fontaine, lInternational Institute of Bibliography (ora noto come
International Federation for Information and Documentation) e nel 1910, la Union of International Associations. Egli fu anche un attivista del movimento della pace che port, alla fine
della I guerra mondiale, alla nascita della Lega delle Nazioni (e della Organizzazione per la
Cooperazione Intellettuale, che divent poi lUnesco).
combinate per fornire innovative funzioni di ricerca e analisi dellinformazione.

Innanzi tutto, pens alla possibilit di costruire, con meccanismi analogici, dei
sistemi che oggi chiameremmo ipertestuali: ide una stazione di lavoro costituita da una scrivania che poteva accedere ad un archivio mobile, montato su
ruote, allinterno del quale un sistema elettro-meccanico permetteva allutente
la ricerca, lettura e scrittura allinterno del database. Lutente non solo poteva
recuperare documenti, ma anche annotare le loro relazioni, le connessioni che
ciascuno ha con tutti gli altri, formando quello che potrebbe essere chiamato il
Libro Universale. Laltro problema molto sentito era quello della decentralizzazione del database, che permettesse una pubblicazione o un accesso remoto alle
biblioteche e centri culturali in tutto il mondo; pens quindi che gli utenti remoti
avrebbero potuto accedere al database tramite un sistema (che Otlet chiamava
di teletautografia o telefotografia), connesso tramite una linea telefonica, che
avrebbe recuperato una immagine facsimile da proiettare su uno schermo della
stazione di lavoro. Infine, Otlet era convinto che il libro fosse solo un mezzo
per trasmettere informazione, e che nuove tecnologie audio e video su pellicole
e dischi fonografici, trasmissioni broadcast di libri e documenti, ecc. potessero
diffondere le informazioni in modo anche pi efficiente e completo.
Nonostante il lavoro di Paul Otlet sia stato completamente dimenticato fino
alla sua riscoperta degli anni 90, possiamo senza dubbio dire che nonostante
le limitazioni tecnologiche dei suoi tempi egli aveva gi chiaramente in mente
luniverso ipermediale oggi costituito dal web.[2]
2.1.2
Vannevar Bush
Uno dei decisivi passi nella formulazione del concetto di ipertesto costituito
dalle proposte contenute in quellarticolo fondamentale - "As We May Think di
Vannevar Bush2 , che tanto influenz i ricercatori tecnologici da quel momento
in avanti. Parlando dei dati organizzati in ordine alfabetico o comunque strutturati in modo rigido, Bush scrisse: La mente umana non lavora in questo modo.
Essa opera in modo associativo. Avendo afferrato un concetto, essa salta istantaneamente al prossimo che viene suggerito dallassociazione di idee, in accordo
con qualche intricata ragnatela di percorsi tracciata dalle cellule del cervello.
E per emulare in modo meccanico questo tipo di funzionamento, o almeno
per supportarlo, Bush concep e propose il memex, un dispositivo personale a
forma di scrivania sul cui piano vi sono schermi su cui possono essere proiettati i
microfilm, una tastiera, un insieme di leve e bottoni. Allinterno della scrivania vi
un sistema elettromeccanico che pu gestire in modo automatico una libreria
che memorizza milioni di pagine dinformazioni sotto forma di microfilm. Le
informazioni possono essere rapidamente richiamate tramite chiavi di ricerca,
che operano sul sistema meccanico di libreria per proiettare sullo schermo le
immagini contenenti le informazioni volute.
Ma se pur innovativo nelle capacit, uno strumento che si limiti a memorizzare e ricercare informazioni ancora convenzionale dal punto di vista filosofico;
dove invece il memex diventa rivoluzionario sta nel fatto che permette allutente
di costruirsi un percorso personalizzato di consultazione, mediante associazioni
2 Vannevar Bush fu il consigliere scientifico del presidente degli Stati Uniti F.D. Roosevelt
durante la seconda guerra mondiale, che lo nomin direttore dellOffice of Scientific Research
and Development. Durante la guerra questufficio coordin le attivit di pi di 6000 scienziati
americani impegnati in tutte le applicazioni militari della scienza.
Figura 2: Vannevar Bush
Figura 3: Memex, cos come ideato da Bush

che possono essere stabilite fra le informazioni. Nel suo articolo, Bush illustr
ed esemplific esattamente il modello che oggi noi, grazie al web, riconosciamo
7
come estremamente familiare - di ipertesto, con pagine che lutente pu navigare spostandosi dalluna allaltra seguendo collegamenti che associano punti di
una pagina a punti su altre pagine semplicemente premendo un bottone sotto il
codice corrispondente, nelle parole originali di Bush.
Per gestire questa massa dinformazioni, Bush non riusciva ancora a pensare
ad un computer. LENIAC, il primo elaboratore elettronico, veniva completato in quegli anni, ma allepoca non era ancora lontanamente pensabile che
un dispositivo di quel genere potesse diventare sufficientemente piccolo, affidabile e soprattutto poco costoso tanto da diventare uno strumento personale.
Ma, qualunque fosse la tecnologia utilizzata per implementarlo, in As We May
Think, Bush prefigurava comunque un mondo in cui esisteva uno strumento
a disposizione delluomo, utilizzato per archiviare informazioni, connetterle fra
loro in strutture metatestuali e ipertestuali, ed estrarne analisi e sintesi che
costituiscano risposte alle domande che luomo si pone.
Possiamo notare come le idee di Vannevar Bush erano non dissimili da quelle
viste in precedenza di Paul Otlet (del lavoro del quale forse molto probabilmente
non era a conoscenza). La differenza principale consisteva nel fatto che mentre
Otlet era pi interessato a permettere allutente laccesso a sterminati database
di informazioni remoti, e mondialmente centralizzati, Bush invece si concentrava
di pi sulle funzioni a supporto del lavoro intellettuale del singolo.[2]
2.1.3
Ted Nelson
La lettura di As We May Think fulmin diversi ricercatori che da quel momento

cambiarono direzione ai propri studi, ed in modo indipendente dedicarono il
resto della propria attivit di ricerca al tentativo di dare vita alla visione di Bush.
Il primo di questi stato Theodore Holm Nelson3 , che possiamo considerare
il pi grande evangelista del concetto di ipertesto. Egli fond allinizio degli
anni 60 e per decenni svilupp il progetto Xanadu, che avrebbe dovuto portare
allo sviluppo di un sistema per organizzare su scala mondiale informazioni in
una struttura ipertestuale e ipermediale. Egli concep Xanadu come un nuovo
mondo di media interattivi, una fusione di letteratura e films, basata su costrutti
arbitrari, interconnessioni e corrispondenze.
Fu proprio Nelson linventore nel 1965 del vocabolo "ipertesto", a cui dava
il significato di sistema di organizzazione di informazioni - testuali e non - in
una struttura non lineare, elastica e non rigida. Una struttura che non poteva
essere mostrata in modo convenzionale su una pagina stampata, ma che richiedeva le capacit di un computer per mostrarla in modo dinamico e navigarla
opportunamente. Nel suo intervento alla 20a conferenza dellACM, egli dichiarava la sua totale adesione alla visione del memex di Bush, e descriveva un
sistema di strutturazione dei files dati chiamato ELF, Evolutionary List File - che rifletteva proprio lorganizzazione ipertestuale. Nello schema di Xanadu,
un database di documenti universale (docuverse) avrebbe permesso lindirizzamento di qualsiasi frammento di qualsiasi documento; in pi Xanadu avrebbe
mantenuto ogni versione di ogni documento (impedendo quindi i problemi di
collegamenti interrotti tipici del web - che oggi ben conosciamo).
3 (17 giugno 1937) un sociologo, filosofo e pioniere dellinformatica statunitense. Gli si
attribuisce il conio di termini quali ipertesto, ipermedia. Questultimo svincola il collegamento
tra contenuti informativi dai soli dati testuali.
Figura 4: Theodore Holme Nelson

Negli anni Nelson matur una particolare attenzione ai problemi di propriet intellettuale che inevitabilmente sorgono, quando dei documenti originali
vengono messi on-line. Xanadu avrebbe dovuto implementare un meccanismo
automatico di pagamento di diritti su tutti i documenti presenti nel docuverse;
inoltre avrebbe dovuto esistere un meccanismo, che Nelson chiam di transclusione che permettesse la citazione di un frammento di documento senza dover
pagare diritti. Purtroppo, come molti visionari, Nelson un perfezionista che
non riesce mai ad accontentarsi di una buona soluzione, ma ha sempre cercato
lottimale, che implementi in modo integrale (oggi diremmo, integralista) i suoi
concetti, senza mezze misure. Egli ritiene, fra laltro, che i collegamenti fra i
vari punti del web debbano essere obbligatoriamente bidirezionali, e che non
debbano essere incorporati dentro il testo stesso, ma debbano essere conservati
in una struttura parallela come in un file system. A causa della ricerca da parte
di Nelson della soluzione ottimale, nei quarantanni della sua vita Xanadu ha su-
bito molte vicissitudini, stata sovvenzionata dagli enti pi vari e perfino dalla
AutoDesk, ma non mai riuscita a partorire alcun sistema realmente usabile.
Ancora oggi il sito del progetto Xanadu continua a diffondere un credo purista
dellipertesto assoluto, e propone in download un sistema inutilizzabile.
In effetti, pi che come tecnologo, Ted Nelson ha avuto successo come evangelizzatore del modello ipertestuale. In questo modo, ha spinto diverse aziende
e altri enti a produrre applicazioni reali, le quali hanno ereditato da Xanadu
moltissime idee.[2]
2.1.4
Tim Berners Lee e le origini del World Wide Web
Uno dei tanti ricercatori che pensavano che le strutture ipertestuali fossero quelle ideali per memorizzare informazioni non strutturate e molto parcellizzate era
Tim Berners-Lee, che lavorava al CERN di Ginevra come consulente e programmatore; durante i suoi anni in Svizzera, egli si era concentrato sulle tecniche di
memorizzazione delle informazioni prodotte non solo al CERN, ma in tutto il
mondo in modo che fosse possibile ritrovarle e rivederle secondo modalit non
lineari e non predefinite.
Figura 5: Tim Berners Lee
10
Tra giugno e dicembre del 1980, Berners-Lee scrisse un programma per gestire le annotazioni, chiamato Enquire Within Upon Everything4 , che girava su
un computer Norsk Data sotto sistema operativo SINTRAN-III.
Enquire permetteva di impostare dei collegamenti tra nodi arbitrari allinterno delle pagine di annotazione; ciascun nodo aveva un titolo, una tipologia, e
una lista di collegamenti bidirezionali associati. Esso venne usato da vari gruppi
di ricerca, ma non ebbe una diffusione significativa al di fuori del CERN.
Nel 1989 Berners-Lee scrisse un memorandum - che ormai diventato parte
della storia di Internet - in cui proponeva un modello di interconnessione delle
informazioni in una struttura a ragnatela, che permettesse di navigarle in modo
non lineare tramite hyper-links (ipercollegamenti). La proposta suscit un discreto interesse e Berners-Lee, insieme a Robert Caillau, si misero al lavoro per
espandere la specifica e definire tutti i meccanismi e i protocolli. La ragnatela
di ipercollegamenti doveva travalicare i limiti del singolo sito, e interconnettere
tutti i siti al mondo che memorizzassero informazioni; si pens pertanto a server
di informazioni, a cui si potesse accedere tramite un client (detto browser ). Le
pagine di informazioni venivano richieste dal browser al server, e il server le forniva in un formato standardizzato chiamato HTML (Hyper-Text Markup
Language) e tramite un protocollo di trasferimento chiamato HTTP (HyperText Transfer Protocol). Ogni pagina ed ogni altra risorsa (immagini, files,
ecc.) poteva essere raggiunta tramite uno specifico indirizzo, denominato URL
(Uniform Resource Locator) che indicava il protocollo da usare per raggiungerlo, il server su cui risiedeva, il percorso allinterno del server, il nome e il tipo
della risorsa in questione.
Figura 6: Architettura Client - Server

4 Informati qui su qualsiasi cosa, era il titolo di un famoso manuale domestico di grande
successo nellInghilterra di epoca vittoriana, il cui compilatore prometteva: Che Voi Desideriate Modellare in Cera un Fiore; Studiare le Regole dellEtichetta; Servire una Salsa per
Colazione o Cena; Pianificare un Pranzo per un Grande Numero di Persone o Uno Piccolo;
Curare un Mal di Testa; Scrivere un Testamento; Sposarvi; Seppellire un Parente; Qualsiasi Cosa Desideriate Fare, Costruire o Averne Diletto, Purch il Vostro Desiderio abbia
Relazione alle Necessit della Vita Domestica, io Spero che non Falliate in Informarvi Qui"
11
Il capo di Berners-Lee, Mike Sendall, approv il progetto per lo sviluppo di

un browser con editor integrato per un sistema ipertestuale, da scrivere su un
NeXT Cube, e Tim si mise al lavoro. Dato che la ragnatela di collegamenti
era da estendere a tutto il mondo, Berners-Lee chiam il suo sistema WorldWideWeb, presto abbreviato in WWW. Nel novembre del 1990, diventava
disponibile la prima pagina sul primo server HTTP della storia. Il giorno di
Natale dello stesso anno, Berners-Lee finiva anche il browser WorldWideWeb,
che veniva poi rilasciato internamente al CERN nel marzo 1991.
In pochi mesi diversi nuovi servers si aggiunsero, dapprima in Europa (specialmente fra gli istituti di ricerca collegati al CERN) e poi negli Stati Uniti e
nel resto del mondo. Nel gennaio del 1993 esistevano circa 50 HTTP servers nel
mondo, nellottobre erano gi 200, e nel giugno del 1994 erano diventati 1500.
[2]
2.1.5
Architettura del WWW
Le tre tecnologie fondamentali alla base del WWW sono:

HTML (HyperText Markup Language), linguaggio derivato da SGML5
per descrivere i documenti presenti nella rete;
URL (Uniform Resource Locator), meccanismo universale di identificazione e indirizzamento delle risorse nella rete;
HTTP (HyperText Transfer Protocol), protocollo client-server di
alto livello adoperato per trasferire documenti e altri file.
Si tratta, quindi, di tecnologie progettate per essere:
semplici;
a prova di futuro (future-proof ).
2.1.6
WorldWideWeb Consortium
Il WWW Consortium stato fondato nel 1994 dallinventore del WWW Tim
Berners-Lee (vd. 2.1.4 ) presso il MIT (Massachussets Institute of Technology) in collaborazione con il CERN. Esso unorganizzazione non governativa
internazionale che ha come scopo quello di sviluppare tutte le potenzialit del
WorldWideWeb. Al fine di riuscire nel proprio intento, la principale attivit
svolta dal W3C consiste nello stabilire standard tecnici per il WorldWideWeb
inerenti sia i linguaggi di markup che i protocolli di comunicazione (es. HTML,
CSS, XML, RDF, OWL,etc.).
Al 2015 il consorzio comprende circa 398 membri tra cui:
5 Lo Standard Generalized Markup Language (SGML), un metalinguaggio definito come
standard ISO (ISO 8879:1986 SGML) avente lo scopo di definire linguaggi da utilizzare per la
stesura di testi destinati ad essere trasmessi ed archiviati con strumenti informatici, ossia per
la stesura di documenti in forma leggibile da computer (machine readable form).
Principale funzione di SGML la stesura di testi chiamati Document Type Definition
(DTD) (vd. 11), ciascuno dei quali definisce in modo rigoroso la struttura logica che devono
avere i documenti di un determinato tipo. Si dice che questi documenti rispetto a SGML
costituiscono un linguaggio obiettivo, ovvero una applicazione.
SGML dovuto soprattutto allopera di Charles Goldfarb e discende dal Generalized Markup Language, linguaggio definito negli anni 1960 presso la IBM, da Goldfarb, Mosher e
Lorie.[9]
12
aziende informatiche di primaria importanza, come Adobe, Apple, Cisco

Systems, Google, IBM, Intel, Microsoft, Oracle, Siemens, Sony e Sun
Microsystems;
compagnie telefoniche come Ericsson, Nokia, NTT DoCoMo;
societ di grandi dimensioni appartenenti ai pi svariati settori, ma strategicamente interessate alla crescita del Web: American Express, AgfaGevaert N. V., Boeing, Chevron-Texaco;
organizzazioni non-profit come la Mozilla Foundation e The Open Group;
universit e istituzioni per la ricerca: il CSAIL del MIT, Inria e altri
membri dellERCIM e Keio University;
altre istituzioni ospitano gli uffici nazionali del Consorzio: per lItalia lISTI di Pisa del CNR; sono numerose le universit e gli istituti di ricerca
tra i pi prestigiosi:Academia Sinica, la Library of Congress, il Los Alamos
National Laboratory, il National Institute of Standards and Technology.
Il consorzio affidato a Tim Berners-Lee, in qualit di direttore, ed al
Dr. Jeffrey Jaffe, in qualit di CEO (Chief Executive Officer, amministratore
delegato).
Attori del W3C Diventare membri del W3C non , ovviamente, cosa gratuita
e la membership fee varia a seconda che si tratti di grandi compagnie o universit
e enti no-profit. Generalmente il costo oscilla fra i 50000$ per le prime e i 5000$
per le seconde.
I lavori del W3C sono gerarchicamente svolti dai seguenti attori:
lAdvisory Committee, composto da un rappresentate per ciascun membro W3C. I compiti di tale commissione sono:
esamina i piani futuri del W3C ad ogni meeting del comitato consultivo;
esamina le proposte presentate dal direttore del W3C;
elegge i componenti dellAdvisory board oltre allAdvisory Board
Chair (una sorta di capo-commissione);
elegge 5 dei 9 partecipanti al Technical Architecture Group.
lAdvisory Board, corpo consultivo il cui compito principale quello di
provvedere linee guida su tematiche quali strategie da adottare, management, affari legali e risoluzione di conflitti. Precisiamo che tale organo non
possiede potere decisionale ma solo consultivo. Vi sono 9 membri eletti dal
comitato consultivo ed un Chair (tecnicamente il direttore del gruppo).
il Technical Architecture Group, il cui compito , generalmente, amministrare le architetture Web. In dettaglio:
documenta e costituisce il consenso6 sulle principali architetture Web;
6 Il consenso il valore cardine del W3C. Esso si consegue, formalmente, nel caso in cui
un numero ragguardevole di membri (in un meeting o tramite scambi di mail) supportano
la decisione in esame e nessuno di essi solleva una obiezione ufficiale. I membri del W3C
possiedono diritto di astensione. Il dissenso si consegue quando almeno un membro del W3C
solleva una obiezione ufficiale.
13
risolve le problematiche relative alle architetture Web;

coordina lo sviluppo di architetture cross-technology sia allinterno
che allesterno del W3C.
I membri del TAG sono 8 pi un Chair (tecnicamente il direttore del
gruppo). Tre componenti del TAG sono nominati dal direttore, gli altri 5
dallAdvisory Committee.
Working Groups, che, generalmente, erogano report tecnici, software,
critiche in merito ai lavori svolti dagli altri gruppi ;
Interest Groups, il cui scopo principale quello di accorpare, riunire
tutti coloro i quali desiderino valutare specifiche tecnologie Web. Si tratta,
in pratica, di un forum per il mutuo scambio di idee;
Coordination Groups, gestiscono e facilitano le comunicazioni fra gruppi allinterno come anche allesterno del W3C;
i chartered groups, costituiti dai rappresentanti dei vari membri del
Consorzio e da esperti di settore, che producono la maggior parte delle
delibere del W3C in accordo con il percorso che le specifiche W3C devono
necessariamente seguire.
Iter delle specifiche W3C Il processo di sviluppo dei technical report consiste nellinsieme di passi e requisiti seguiti dai gruppi di lavoro del W3C atti
a standardizzare le tecnologie per il Web. Tale processo caratterizzato dai
seguenti principi da rispettare:
supporto di metodologie multiple di sviluppo di una specifica;
massimizzazione del consenso riguardo ai contenuti di un report tecnico;
massimizzazione della qualit in termini tecnici ed editoriali;
promozione della consistenza fra differenti specifiche;
promozione di tecnologie royalty-free ed interoperabili.
W3C segue i seguenti passi (Fig. 7) per produrre i cosiddetti Reccomendation
(referenze):
pubblicazione del First Public Working Draft, cio il primo stadio di
avanzamento che si consegue nel momento in cui il lavoro di un Working
Group soddisfa i requisiti minimi di avanzamento7 ;
7 Per poter procedere al livello di avanzamento successivo i documenti esaminati dai
Working Group devono:
registrare la decisione del gruppo di procedere con lavanzamento;

ottenere lapprovazione del Direttore;
fornire una documentazione pubblica di tutti i cambiamenti sostanziali al rapporto
tecnico rispetto alla pubblicazione precedente;
fornire, formalmente, tutte le risoluzioni ai problemi presenti nella pubblicazione
precedente.
E evidente che per un First Public Working Draft non esistono versioni precedenti: ne
risulta che lapprovazione a tale livello pressoch automatica.
14
pubblicazione, non strettamente necessaria, di un lavoro di revisione del

Public Working Draft;
pubblicazione di un Candidate Recommendation, cio il secondo stadio di avanzamento che si consegue nel momento in cui il lavoro di un
Working Group soddisfa, in aggiunta ai requisiti minimi di avanzamento,
dei requisiti aggiuntivi8 ;
pubblicazione di un Proposed Recommendation, cio il terzo stadio
di avanzamento che si consegue nel momento in cui il lavoro di un Working Group soddisfa, in aggiunta ai requisiti minimi di avanzamento, dei
requisiti aggiuntivi9 ;
pubblicazione di un W3C Recommendation, cio lo stadio ultimo di
avanzamento che si consegue nel momento in cui il lavoro di un Working Group soddisfa, in aggiunta ai requisiti minimi di avanzamento, dei
requisiti aggiuntivi10
I Working Group Notes, Member Submissions, Staff Comments,
Team Submissions non sono in alcun modo documenti normativi, non hanno,
quindi, alcun valore di ufficialit. [10][8]
8
Tali requisiti sono:
mostrare che la specifica rispetta tutti i requisiti indicati dal Working Group o,
nelleventualit che essi siano stati alterati oppure scartati, spiegarne le motivazioni;
documentare i cambiamenti di dipendenze durante lo sviluppo della specifica;
documentare quanto adeguatamente sar dimostrata lesperienza implementativa;
specificare un tempo limite per i commenti (almeno 4 settimane dopo la pubblicazione;
anche di pi per documenti complessi);
mostrare che la specifica ha ricevuto unampia analisi ed indicari i vari fattori di rischio.
9 E necessario venga specificato un tempo limite entro cui lAdvisory Committee recensisca
la specifica (almeno 28 giorni dopo la pubblicazione del Proposed Recommendation). In
aggiunta a ci un Working Group deve:
mostrare una esperienza implementativa adeguata;

mostrare che il documento abbia ricevuto unampia analisi;
mostrare che tutte le problematiche raccolte durante la fase di Candidate
Recommendation siano state formalmente esposte;
mostrare tutte le problematiche venute alla luce dopo la fase di Candidate
Recommendation
.
Il direttore deve:
annunciare la pubblicazione di un Proposed Recommendation allAdvisory Committee
e pu, a sua discrezione, approvare un Proposed Recommendation con una esperienza
implementativa minima fornendo valide motivazioni a riguardo.
10
Una Recommendation deve:
identificare dove siano presenti gli errata;

non pu contenere cambiamenti significativi dal Proposed Recommendation da cui
tratta.
Il direttore deve annunciare la pubblicazione di una nuova W3C Reccomandation
allAdvisory Committee, ai gruppi del W3C e al pubblico.
15
Figura 7: Processo di stesura di un Recommendation

2.1.7
Web Browser
Il Web browser il principale tipo di applicazione client nel WWW che consente allutente di navigare le pagine Web mediante collegamenti ipertestuali. I
primi browser, sorti nei primi anni 90, erano solo testuali con conseguente bassa
usabilit da parte dellutente finale. Solo nel 1992 viene realizzato il primo browser grafico comandato via mouse, Mosaic, mediante il quale inizia lesplosione
della popolarit del WWW.
Levoluzione tecnologica stata a lungo rallentata dalla cosiddetta browser
war che ha visto contesi i browser Internet Explorer e Netscape. Negli ultimi
anni, tuttavia, sono stati compiuti numerosi avanzamenti tecnologici.
Architettura di un Web browser Un Web browser consta, generalmente,
di 8 sottosistemi principali incluse le dipendenze fra essi. Come evidenziato
nella Fig. 9 essi sono:
User Interface, il layer presente fra lutente e il browser engine.
Regola funzionalit quali le toolbar, progresso nel caricamento della pagina, gestione intelligente dei download, opzioni preferite e stampa. Pu
essere integrato nellambiente desktop cos da consentire la gestione e la
comunicazione della sessione del browser con altri applicativi desktop.
Recenti innovazioni in questo sottosistema sono:
navigazione a schede (tab);
estensioni, componenti aggiuntivi che permettono di integrare nuove
funzionalit nella navigazione o nella gestione dei dati utente;
barra di ricerca personalizzabile;
supporto allinterazione mediante gesti ;
maggior risalto a potenziali rischi per la sicurezza (connessioni non
sicure, phishing, etc.).
Browser Engine, implementa uninterfaccia di alto livello verso il Rendering Engine. Permette di caricare un URI e supporta le azioni primitive del browser quali forward, back e reload. Inoltre funge da "aggancio"
per consentire la visione di aspetti eterogenei della sessione corrente del
browser come la percentuale di caricamento della pagina o gli eventi JavaScript. Consente di gestire i plugin, quei componenti aggiuntivi che permettono di visualizzare particolari contenuti incorporati nelle pagine Web
(generalmente contenuti multimediali e interattivi per RIA - Rich Internet Applications 11 ) Infine consente il querying e la modifica dei parametri
del Rendering Engine;
11 Applicazioni web che possiedono le caratteristiche e le funzionalit delle applicazioni
desktop, senza per necessitare dellinstallazione sul disco fisso.
16
Rendering Engine, fornisce una rappresentazione visuale per un URI

dato. Consente di visualizzare documenti redatti in HTML e XML, opzionalmente realizzati mediante CSS, cos come contenuti embedded quali
le immagini. Calcola il corretto layout della pagina e pu adoperare algoritmi di reflow per modificare dinamicamente la posizione degli elementi
nella pagina. Gestisce le interazioni dellutente e passa gli eventi generati
al JavaScript interpreter.
In tale sottosistema presente il parser HTML.
Recenti innovazioni in tale sottosistema sono:
separazione dei processi : il processo del browser engine crea un nuovo processo per il rendering engine di ogni tab (pagina) aperto. Nonostante ci comporti un leggero incremento duso delle risorse, si
impedisce a crash di sistema o a violazioni di sicurezza, verificatesi
su di una pagina, di impattare sulle altre.
Networking, implementa protocolli di trasferimento file quali HTTP e
FTP. Traduce i differenti insiemi di caratteri e risolve i tipi MIME per i file.
Pu anche implementare una cache delle risorse recentemente recuperate;
JavaScript Interpreter, valuta il codice JavaScript (anche chiamato
ECMA-Script12 ) che pu essere incluso nelle pagine web. JavaScript
un linguaggio di scripting object-oriented sviluppato da Netscape. Alcune funzionalit JavaScript, quali aprire finestre di pop-up, possono essere
disabilitate dal Browser Engine o dal Rendering Engine per ragioni di
sicurezza.
JIT (Just-In-Time) Compiler
il codice, appena prima di essere eseguito per la prima volta,
viene compilato;
sfruttando ottimizzazioni prodotte dalla compilazione e il riuso delle parti gi compilate, le prestazioni possono migliorare
sensibilmente rispetto ad un interprete puro.
Figura 8: Motori JavaScript con JIT Compiler

12 EuropeanComputerManufacturersAssociationScript un linguaggio di scripting standardizzato dalla ECMA International nella specifica ECMA-262 e nellISO/IEC 16262. Si tratta di un linguaggio largamente adoperato per lo scripting client-side nella forma di famose
implementazioni quali JavaScript, JScript e ActionScript.
17
XML Parser, effettua il parsing dei documenti XML in un albero DOM.

E il sottosistema pi riadoperato dellintera architettura poich conveniente riadoperare un parser XML esistente piuttosto che ricrearlo da zero.
I documenti elaborati possono essere scambiati con i Web server mediante
paradigma AJAX;
Display Backend, consente di adoperare primitive legate al disegno e
alle finestre, di adoperare widget e fornisce un insieme di font. Pu essere
accorpato al sistema operativo.
Accelerazione hardware: sono sfruttate le istruzioni dedicate messe a disposizione dalle recenti generazioni di hardware grafico al fine
di:
migliorare la qualit di immagini e testo e la fluidit di scorrimento;
migliorare la resa degli effetti di animazione e transizione;
migliorare la riproduzione dei filmati incorporati nelle pagine;
permettere luso di grafica 3D nelle pagine;
ridurre il consumo energetico (essenziale per notebook, netbook,
tablet e smartphone).
Data Persistence, memorizza su file system differenti dati associati alla
sessione di browsing corrente. Si tratta di dati di alto livello, quali i
segnalibri o settaggi delle toolbar, oppure dati di basso livello, quali cookie,
certificati di sicurezza, cache.
Recenti innovazioni in questo sottosistema sono:
uso di database embedded (SQLite) per maggiore efficienza e scalabilit;
sincronizzazione dei dati (mediante server remoto) tra calcolatori
diversi associati allo stesso utente.
Figura 9: Architettura di un Web browser

LHTML parser inserito di proposito nel sottosistema rendering engine rispetto al parser XML poich questultimo un componente generico e riusabile
18
Figura 10: Differenti tipi di rendering engine

costituito da una interfaccia ben definita mentre il primo, per ragioni di performance e di interpretazione di codice HTML non standard, preferibile sia
integrato in un sottosistema di render.
Architettura di Mozilla Firefox La suite Mozilla (Fig. 11) stata rilasciata
come open source da Netscape nel 1998. Da allora la maggior parte dei sistemi
che la compongono sono stati riprogettati e riscritti, con conseguente aggiunta
di numerose funzionalit aggiuntive.
Gli obiettivi che gli sviluppatori di Mozilla perseguono sono:
ampio supporto dei web standard;
ampio supporto multipiattaforma;
velocit nel rendering delle pagine Web.
La maggior parte del codice scritto in C++ nonostante ampie sezioni dellinterfaccia utente siano realizzate in JavaScript (alcune componenti legacy sono
scritte in C). Il sottosistema User Interface suddiviso in due sottosistemi cos
da garantire il loro riutilizzo in altre applicazioni della suite Mozilla come, ad
esempio, client di mail o news.
Tutte le operazioni di data persistence sono svolte dal meccanismo di profilazione proprietario Mozilla che memorizza dati sia di alto livello, quali i segnalibri,
sia di basso livello, quali le pagine cache.
Il rendering engine pi grande e complesso di quello della maggior parte
degli altri browser: una motivazione costituita dalla capacit di Mozilla di
effettuare correttamente il parsing e il rendering di pagine HTML malformate o
errate. In aggiunta a ci, il rendering engine si occupa di renderizzare le interfacce utente cross - platform. La UI , infatti, specificata nel linguaggio XUL
(Extensible User Interface Language), che mappato da apposite librerie specifiche a seconda della piattaforma adoperata dallutente finale. Il core di Mozilla
stato reingegnerizzato in un componente runtime denominato XULRunner
il quale consente ad altre applicazioni di sfruttare i sottosistemi browser. Ci
consente agli sviluppatori di adoperare le moderne tecnologie web per realizzare
applicativi molto pi elaborati delle consuete applicazioni browser - based.[1]
19
Figura 11: Architettura del browser Mozilla Firefox

Proxy based browser E un tipo di architettura (Fig. 25) in cui il browser non accede direttamente alle risorse sul Web, ma tutte le richieste vengono filtrate da un proxy server (gestito dal fornitore del browser) affinch sia
possibile:
diminuire la latenza sfruttando le connessioni del proxy;
comprimere e codificare i dati con conseguente:
risparmio di banda (tempo di trasferimento e costi di connessione);
possibilit di visualizzare pagine complesse anche su dispositivi dalle
risorse di calcolo limitate (cellulari).
Figura 12: Architettura di un proxy - browser

Generalmente il tempo complessivo di caricamento di una pagina Web (turnaround
time) pari a:
T = Lcs + Tcs + S + C
dove:
Lcs , rappresenta la latenza di connessione client - server di origine;
20
(1)
Tcs , rappresenta il tempo di trasferimento dei dati;

S, rappresenta il tempo di elaborazione del server;
C, rappresenta il tempo di elaborazione del client (parsing e rendering).
Il tempo complessivo di caricamento di una pagina Web per un browser
proxy - based , invece, pari a:
T 0 = Lcp + Lps + Tcp + Tps + S 0 + C 0
(2)
dove:
Lcp , rappresenta la latenza di connessione client - proxy;
Lps , rappresenta la latenza di connessione proxy - server di origine;
Tcp , rappresenta il tempo di trasferimento dei dati client - proxy;
Tps , rappresenta il tempo di trasferimento dei dati proxy - server di origine;
S, rappresenta il tempo di elaborazione del server;
C, rappresenta il tempo di elaborazione del client (parsing e rendering).
I browser proxy - based puntano ad ottenere T 0 < T dati i seguenti accorgimenti:
Lcp , Lps << Lcs , poich il fornitore del browser offre pi proxy geograficamente distribuiti nei centri nevralgici di Internet;
Tps << Tcs , poich i proxy effettuano caching ed hanno elevata larghezza
di banda;
Tcp << Tcs , poich il proxy comprime i dati;
C 0 < C, poich il proxy trascodifica i dati in un formato pi rapidamente
elaborabile dal browser.
Compatibilit dei browser Nel periodo intercorso fra il 1995 e il 2003 (browser war ) i maggiori browser hanno introdotto caratteristiche ed estensioni non
standard che hanno minato la compatibilit cross - browser delle applicazioni
Web.
Le versioni pi moderne di tutti i maggiori browser pongono attenzione alla
compatibilit con gli standard.
Nonostante ci, per essere certi che la propria Web application sia correttamente riprodotta e funzionante, occorre testarla su tutti i browser che
costituiscono il proprio target.
Ladozione di template (CSS) e librerie (JavaScript) gi testati per la
compatibilit cross - browser semplifica notevolmente il lavoro.
21
Figura 13: Pila TCP/IP
HTTP
3.1
Introduzione
HTTP (HyperText Transfer Protocol ) un protocollo di livello applicativo

(Fig. 13) per sistemi informativi ipermediali collaborativi e distribuiti [3].
E nato per lo scambio di documenti ipertestuali, ma risulta essere utilizzato,
attualmente, in un vasto insieme di applicazioni.
3.2
Principio di funzionamento di HTTP
Il modello alla base del protocollo HTTP quello client - server (Fig. 14).
Si tratta, quindi, di un protocollo di tipo richiesta - risposta, laddove tutte
le richieste effettuate tramite protocollo TCP vengono, di default, trasmesse
mediante porta 80.
HTTP presenta due caratteristiche basilari. Esso infatti:
generico, cio indipendente dal formato dati con cui vengono trasmesse le
risorse. Pu funzionare per documenti ipertestuali HTML, per file binari,
eseguibili, oggetti distribuiti o altre strutture dati;
stateless, cio il server non tenuto a mantenere informazioni che persistano tra una connessione e la successiva sulla natura, identit e precedenti
richieste effettuate da un client. Il client tenuto a ricreare da zero il contesto necessario al server per rispondere. Riassumendo: non vi memoria
delle richieste effettuate.
Figura 14: Schema di funzionamento del modello client - server
22
3.3
Versioni di HTTP
HTTP esistito in tre versioni:

0.9, protocollo client - server di sola richiesta di risorse HTML, senza
flessibilit n nella direzione, n nel formato delle risorse. Consente luso
esclusivo del metodo di richiesta GET;
1.0, prima versione standard. Protocollo generico e privo di stato mediante il quale vengono introdotti ulteriori metodi di richiesta delle risorse
[RFC:1945 ];
1.1, versione attuale di HTTP, introduce nuovi meccanismi di caching,
permette multihoming (pi siti sullo stesso host) e connessioni persistenti.[4][5][3][6]
3.4
Entit
Analizziamo lo scenario di applicazione di una connessione HTTP evidenziandone gli attori:

Client, applicazione che richiede una connessione HTTP, con lo scopo di
inviare richieste;
Server, applicazione che accetta connessioni HTTP e genera risposte;
User agent, client che inizia una richiesta HTTP. Tipicamente un browser, ma pu anche essere un bot 13 o un altro tool come ad esempio
curl 14 ;
Origin server, il server che possiede fisicamente la risorsa richiesta;
Proxy, applicazione intermediaria che agisce sia da client che da server.
Le richieste sono soddisfatte autonomamente, o passandole ad altri server,
con possibile trasformazione, controllo, verifica;
Gateway, applicazione che agisce da intermediario per qualche altro server. A differenza del proxy, il gateway riceve le richieste come fosse lorigin server: il client pu essere alloscuro che si tratti effettivamente del
gateway;
Tunnel, programma intermediario che agisce da trasmettitore passivo di
una richiesta HTTP. Il tunnel non fa parte della comunicazione HTTP,
anche se pu essere stato attivato da una connessione HTTP;
Cache, memoria locale di unapplicazione e il sistema che controlla i meccanismi della sua gestione ed aggiornamento. Qualunque client o server
pu utilizzare una cache.
13 Abbreviazione di robot. Si tratta di unapplicazione automatica che richiede e scarica pagine HTML e siti web per scopi quali lindicizzazione, la catalogazione, la verifica di correttezza
sintattica. E uno user agent anche se non serve direttamente utenti.
14 Client URL Request Library un software, composto da una libreria e da un tool in riga
di comando, il cui scopo quello di trasferire dati adoperando differenti protocolli. Il cURL
project si compone di due prodotti, libcurl e cURL. E stato rilasciato per la prima volta
nel 1997. I protocolli supportati sono: HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP,
LDAP, LDAPS, DICT, TELNET, FILE, IMAP, POP3, SMTP,RTSP.[12]
23
3.5
Struttura dei messaggi HTTP
I messaggi HTTP seguono la Backus - Naur Form.

3.5.1
Backus - Naur Form
La BNF (Backus-Naur Form o Backus Normal Form) una metasintassi, ovvero un formalismo attraverso il quale possibile descrivere la sintassi di linguaggi
formali (il prefisso meta ha proprio a che vedere con la natura circolare di questa
definizione). Si tratta di uno strumento molto usato per descrivere, in modo preciso e non ambiguo, la sintassi dei linguaggi di programmazione, dei protocolli
di rete.
In termini formali, la BNF pu essere vista come un formalismo per descrivere grammatiche libere dal contesto.
La BNF fu proposta da John Backus nel corpo della definizione del linguaggio di programmazione ALGOL. Lacronimo BNF era inizialmente inteso come
Backus Normal Form ("forma normale di Backus"); su suggerimento di Donald
Knuth, fu in seguito riletto come Backus-Naur Form, in onore di Peter Naur, un
altro membro del comitato ALGOL e pioniere dei linguaggi di programmazione
(e pi in particolare della realizzazione di compilatori).
Una specifica BNF un insieme di regole di derivazione, ciascuna espressa
nella forma:
< simbolo >::= _espressione_
o nella forma equivalente:
< simbolo > _espressione_
Le due forme sono assolutamente equivalenti. La prima forma (che verr
utilizzata nel seguito) utilizza caratteri ASCII standard ed quella pi utilizzata
per scrivere grammatiche che devono essere utilizzate dai calcolatori e lette in file
di testo. La seconda forma meno utilizzabile nella pratica ma comune nei
testi e negli articoli di informatica teorica in quanto meglio esprime loperazione
di derivazione delle stringhe di un linguaggio a causa dellapplicazione delle
regole di derivazione.
Nelle regole di derivazione <simbolo> (i caratteri < e > sono obbligatori)
viene detto un simbolo nonterminale e _espressione_ costituita da una
o pi sequenze di simboli terminali o nonterminali (identificati dal fatto di
essere racchiusi tra < >); se le sequenze sono pi di una esse sono separate
dalla barra verticale |. La regola esprime il fatto che il nonterminale a sinistra
della regola pu essere sostituito da una qualsiasi delle sequenze indicate sulla
destra. Inoltre in una sequenza alcuni simboli o sottosequenze possono essere
indicati come opzionali racchiudendoli fra parentesi quadre.
I simboli che non appaiono mai a sinistra di una regola di derivazione sono
detti terminali. I terminali sono in un certo senso il punto di arrivo, perch rappresentano elementi che si troveranno effettivamente in un testo scritto secondo
le regole sintattiche che la specifica BNF descrive. I simboli nonterminali, viceversa, sono strumenti utilizzati esclusivamente dalla BNF e sono racchiusi tra <
>; si pu dire che essi rappresentano gli elementi astratti della grammatica.
BNF rules
Le seguenti regole sono usate nella descrizione dei messaggi HTTP:
OCTET = <qualsiasi sequenza di 8 bit>
24
CHAR = < qualsiasi carattere US-ASCII (octet 0 - 127)>

UPALPHA = <qualsiasi lettera maiuscola US-ASCII "A".."Z">
LOALPHA = <qualsiasi lettera minuscola US-ASCII "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <qualsiasi numero US-ASCII "0".."9">
CTL = <qualsiasi carattere di controllo US-ASCII (octets 0 - 31) e DEL
(127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, spazio (32)>
HT = <US-ASCII HT, tab orizzontale (9)>
<"> = <US-ASCII, virgolette (34)>
Esempio di BNF Immaginiamo di voler descrivere in modo formale, preciso
e non ambiguo le regole che bisognerebbe seguire quando si scrive un indirizzo
su una lettera.
In particolare cominciamo con un esempio che contiene solo simboli non
terminali; la sua specifica BNF potrebbe essere grosso modo come segue:
<indirizzo postale> ::= <destinatario> <indirizzo> <localit>
<destinatario> ::= [<titolo>] [<nome>|<iniziale>] <cognome> <a capo>
<indirizzo> ::= <via> <numero civico> <a capo>
<localit> ::= [<CAP>] <comune> <provincia>
Questo frammento di specifica pu essere tradotto in italiano come segue:
un indirizzo postale include un destinatario, seguito da un indirizzo, seguito
da una indicazione di localit; il destinatario comprende sicuramente un cognome, a cui si possono far precedere, nellordine, un titolo (come Sig. o Dott.
ecc.) e un nome o una iniziale; lindirizzo comprende necessariamente una indicazione di via (o piazza, viale, ecc.) e il numero civico; lindicazione della
localit comprende un codice di avviamento postale opzionale, seguito dal nome
del comune e dalla provincia. [11]
25
3.5.2
HTTP: tipologia messaggi
I messaggi HTTP (versione 1.1) consistono in richieste da un client ad un server

ed in risposte da un server ad un client:
HTTP-message = Request | Response.
Entrambi i tipi di messaggio contengono una start - line, zero o pi header
field (header), una linea vuota che attesti il termine degli header field e un
message - body (corpo del messaggio):
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line
= Request-Line | Status-Line
Al fine di garantire robustezza, i server dovrebbero ignorare linee vuote ricevute al posto di una Request - Line. In altre parole, se il server legge il flusso
dati e allinizio del messaggio riceve un CRLF (Carrier Return Line Feed,
ritorno a capo)(vd. 3.5.1) come primo elemento deve ignorare questultimo.
3.5.3
HTTP: Header
Ciascun header consiste di un nome seguito dai due punti (:) a cui segue il
valore attribuito al campo.
I campi sono case - insensitive.
I valori possono essere preceduti da un numero imprecisato di (Linear White
Space, spazi vuoti lineari)(vd. 3.5.1) anche se preferibile inserire un singolo
SP(vd. 3.5.1). Gli header field possono estendersi su pi righe a patto che
ciascuna riga extra sia preceduta da un SP o da un HT (vd. 3.5.1).
Gli header sono in formato MIME (vd. 3.5.4).
3.5.4
HTTP: MIME
MIME (Multipurpose Internet Mail Extensions) un sistema di comunicazione per permettere la spedizione tramite e-mail (e, per estensione, sul Web
tramite HTTP) di dati binari codificati.
A ciascun flusso di dati associata una intestazione del tipo Content-type:
object/format dove:
object specifica il tipo di oggetto codificato (text, image...);
format indica il formato con cui strutturato (ad esempio, per un oggetto
text pu essere plain, html);
26
ogni coppia oggetto/formato costituisce un tipo MIME (MIME type o

content type).
Lelenco ufficiale di tipi MIME standardizzati gestito dallo IANA (Internet
Assigned Numbers Authority). Per flussi di tipi non standardizzati, si usa il
tipo generico application/octet-stream.
MIME nato perch i sistemi basati su SMTP15 trasportano correttamente
al pi i primi 128 caratteri del codice ASCII (caratteri alfanumerici), mentre allinterno di un file binario i byte possono avere tutti e 256 i valori possibili; quindi
necessario prevedere un sistema di codifica. Content-Transfer-Encoding
indica la codifica da adoperare per la spedizione delloggetto. MIME prevede
alcune codifiche standard:
7 bit, nessuna operazione di codifica stata effettuata sul contenuto del
messaggio. In questo caso i dati possono essere rappresentati in gruppi di
sette bit, ognuno dei quali rappresenta un carattere ASCII; questo anche
il valore assunto come default se il campo non viene specificato;
8 bit, nessuna operazione di codifica stata effettuata sul contenuto
del messaggio. Possono essere presenti caratteri non appartenenti al set
ASCII; cio, suddividendo il messaggio in linee di 8 bit ciascuna e associando ad ogni linea un carattere ASCII, si possono ottenere delle sequenze
di caratteri apparentemente senza significato;
binary, nessuna operazione di codifica stata effettuata sul contenuto del
messaggio. Il contenuto del messaggio in formato binario (unimmagine,
un file audio, ecc.);
quoted-printable, indica che unoperazione di codifica gi stata applicata ai dati, in modo da trasformare il messaggio in una sequenza di
caratteri ASCII (se il messaggio originario era gi costituito da un testo ASCII, questa codifica lo lascia sostanzialmente inalterato). Lo scopo
principale di questa codifica di mettere i dati in un formato che difficilmente subir delle trasformazioni da parte dei vari sistemi che costretto
ad attraversare, prima di giungere a destinazione;
base64, indica che sui dati stata effettuata unoperazione di codifica,
detta base64. Con questa operazione il messaggio viene trasformato in una
sequenza di caratteri appartenenti ad un sottogruppo del set di caratteri
ASCII (le lettere maiuscole da A a Z, quelle minuscole da a a z, i numeri
da 0 a 9, il carattere + ed il carattere \). In questo modo, ogni carattere
codificato pu essere rappresentato con sei bit. Loperazione di codifica
consiste nel suddividere la sequenza dei bit in ingresso (il messaggio) in
gruppi di 24 bit; ogni gruppo di 24 bit viene diviso in quattro gruppi di
sei bit, ad ognuno dei quali si associa il corrispondente carattere ASCII
appartenente al sottogruppo specificato.
[7]
15 Simple Mail Transfer Protocol (SMTP) il protocollo standard per la trasmissione via
internet di e-mail
27
3.5.5
HTTP: Body
Il message - body (se presente nel messaggio HTTP) adoperato per trasferire
lentity - body associato alla richiesta o alla risposta. Message - body e
Entity - body differiscono tra loro solo se applicata qualche codifica nella
trasmissione (transfer - coding):
message-body = entity-body | <entity-body codificato come specificato dallheader Transfer - Encoding>.
La presenza di un message - body in una richiesta segnalata dalla presenza
dellheader Content - Length o Transfer - Encoding. Un message - body
non deve essere incluso in una richiesta se il metodo adoperato non permette,
secondo le specifiche, di inviarne uno. Se esso viene inserito ugualmente, nonostante il metodo adoperato lo vieti, il server ignorer il message - body nel
momento in cui analizzer la richiesta stessa.t.
La presenza di un message - body in una risposta dipendente sia dal
metodo delle richiesta che dallo status code della risposta. Ad esempio tutte le risposte al metodo HEAD non includeranno un message - body. E, allo
stesso modo, tutte le risposte con status code pari a 1xx (informational, informativa), 204 (no content, nessun contenuto) e 304 (not modified, non
modificato). Tutte le altre risposte necessitano di message - body anche se esso
fosse di lunghezza zero (zero length).
3.5.6
HTTP: Message Length
Il transfer - length di un messaggio dato dalla lunghezza del message - body

cos come appare nel messaggio dopo che siano state applicati eventuali transfer
- coding.
Quando un message - body incluso in un messaggio il suo transfer - length
determinato mediante uno dei seguenti modi (in ordine di precedenza):
qualsiasi messaggio di risposta che non includa un message - body termina
sempre con la prima linea vuota presente dopo gli header field ;
se presente un header transfer - encoding e ha un valore differente dallidentit, allora il transfer - length calcolato mediante il chunked transfer
- coding 16 , a meno che il messaggio sia terminato dalla chiusura della
connessione;
se presente lheader Content - Length, il valore decimale del suo ottetto
rappresenta sia lentity - length che il transfer - length;
se il messaggio adopera il tipo multipart/byteranges, e il transfer length non altrimenti specificato, allora lo stesso tipo multipart ad
individuare il transfer - length;
il server che lo calcola chiudendo la connessione.
16
Il chunked encoding modifica il body di un messaggio cos da trasmetterelo mediante

una serie di chunk (spezzoni), ciascuno con un proprio indicatore di grandezza e seguito da
una coda (opzionale) per eventuali header.
28
Per ragioni di compatibilit con HTTP/1.0, le richieste effettuate con HTTP/1.1

contenenti un message - body devono includere un Content - Length valido a
meno che non si sappia a priori che il server a cui indirizzato il messaggio
rispetta lo standard 1.1.
3.5.7
HTTP: Header generici
Ci sono alcuni header che possono essere applicati sia per richieste che per
risposte e che non riguardano direttamente la particolare entit da trasferire:
Cache - Control, usato per specificare le direttive a cui devono soggiacere tutti i meccanismi di caching. Ci per garantire che i meccanismi di
caching non interferiscano con la trasmissione del messaggio. Le direttive
di caching sono unidirezionali cio possono essere differenti a seconda che
si tratti di una richiesta o di una risposta;
Connection, consente al mittente di specificare le opzioni desiderate per
una specifica connessione e non pu essere inoltrato da proxy;
Date, rappresenta la data e lora in cui il messaggio stato originato;
MIME - Version, indica la versione MIME adoperata per la trasmissione
(1.0);
Pragma, adoperato per includere particolari specifiche. Ad esempio
quando inoltrata la direttiva no-cache la richiesta deve essere inoltrata
direttamente allOrigin server ;
Trailer, indica che linsieme degli header field presente nella coda del
messaggio codificato mediante chunked transfer - coding;
Transfer - Encoding, usato per specificare leventuale codifica dei dati
applicata al message - body;
Upgrade, consente al client di specificare quali protocolli addizionali esso
supporta e consente al server di effettuare lo switching fra essi qualora lo
ritenesse opportuno;
Via , generalmente adoperato dai gateway e dai proxy per indicare i
protocolli e gli attori intermediari posti fra lo user agent e il server in un
messaggio di richiesta, e fra lorigin server e il client in un messaggio di
risposta;
Warning, adoperato per trasferire informazioni addizionali in merito
allo stato o alla trasformazione di un messaggio che potrebbe non evincersi
dal messaggio stesso.
3.5.8
HTTP: Header field dellentit
Essi danno informazioni circa il body del messaggio, o, in sua assenza, sulla
risorsa specificata. Nello specifico:
Content - Type, indica il tipo MIME dellentit acclusa. Questo header
obbligatorio in ogni messaggio che abbia un body;
29
Content - Length, indica la lunghezza in byte del body. Obbligatorio in

ciascun messaggio che disponga di un body;
Content - Encoding, Content Language, Content Location, Content - MD5, Content - Range, indicano, rispettivamente, la codifica, il
linguaggio, lURL della risorsa specifica, il valore di digest MD5 e il range
richiesto della risorsa;
Expires, indica la data dopo la quale la risorsa non considerata pi valida e deve necessariamente essere richiesta nuovamente allorigin server ;
Last - Modified, la data e lora dellultima modifica. Serve per decidere
se la copia posseduta ancora valida o meno.
3.5.9
HTTP: Request message
Un messaggio di richiesta (Fig. 15) inviato da un client ad un server include

nella prima linea del messaggio stesso:
metodo da applicare alla risorsa in trasmissione;
URI della risorsa in trasmissione;
protocol version in uso.
Figura 15: Messaggio di richiesta
Request - Line La request - line, come su visto, incomincia con un metodo,

segue con lidentificativo univoco URI della risorsa e termina con la versione
del protocollo HTTP adoperata: i tre campi sono intervallati fra loro da un
SP (vd. 3.5.1) e non possono contenere CRLF(vd. 3.5.1) fatta eccezione per il
termine della request - line.
Metodi Il campo Method indica il metodo da adoperare sulla risorsa identificata dalRequest - URI. I metodi sono case - insensitive. Inoltre un metodo
HTTP pu essere:
sicuro, non genera cambiamenti allo stato interno del server;
idempotente, leffetto di una stessa richiesta su pi server lo stesso di
quello generato su pi server.
Essi sono:
30
OPTIONS, rappresenta una richiesta di informazioni riguardo le opzioni

di comunicazione adoperabili sulle interazioni client - server identificate dal
request - uri; nel dettaglio il metodo permette al client di determinare le
operazioni o i requisiti associate ad una risorsa, le caratteristiche del server,
senza effettuare, di fatto, una operazione di resource action (modifica o
cancellazione di una risorsa) o resource retrieval (scaricamento di una
risorsa);
GET, consente di recuperare qualsiasi informazione (sottoforma di entit)
sia identificata da un URI. La semantica del GET cambia a seconda che
si tratti di un:
assoluto, viene richiesta una risorsa senza ulteriori specificazioni;
condizionale, se il messaggio di richiesta include header del tipo
If-Modified-Since, If-Unmodified-Since, If-Match, If-NoneMatch, If-Range (vd. 3.5.9). Un GET condizionale richiede che
unentit sia trasferita solo date le condizioni contenute negli eventuali header. Lutilit consiste nella riduzione dellutilizzo di banda,
consentendo, ad esempio, il refreshing di una risorsa mediante cache
piuttosto che tramite richieste multiple.
parziale, se il messaggio include un header Range (vd. 3.5.9). Un
GET parziale richiede solo ed esclusivamente la parte dellentit richiesta dallheader. Lutilit risiede nella possibilit di ridurre lutilizzo di rete. Ad esempio, in caso di entit parzialmente scaricate possibile adoperare un GET parziale per non dover trasferire
nuovamente i dati gi posseduti dal client.
HEAD, identico al GET fatta eccezione per il fatto che il server non
deve restituire un message - body. E spesso adoperato per testare
la validit di un URI, cio la risorsa esiste e non di lunghezza zero;
laccessibilit di un URI, cio la risorsa accessibile presso il server
e non sono richieste procedure di autenticazione del documento;
la coerenza di cache di un URI, cio se la risorsa non stata
modificata nel frattempo, non ha cambiato lunghezza, valore hash o
data di modifica.
POST, utilizzato per richiedere allorigin server di accettare lentit
allegata alla richiesta come una subordinata (aggiuntiva) alla risorsa
(generalmente preesistente) indicata nellURI della richiesta. Esempi tipici
sono:
annotazione di risorse preesistenti;
postare un messaggio su un forum, su un newsgroup, in una mailing
list o simili;
effettuare il submit di un form;
estendere un database attraverso una operazione di append.
POST non sicuro n idempotente.
Il server pu rispondere ad una richiesta POST in tre modi:
31
200 OK, dati ricevuti e trasmessi alla risorsa specificata; presente

un body nel messaggio di risposta;
201 CREATED, dati ricevuti, la risorsa non esisteva ed stata
creata;
204 NO CONTENT, dati ricevuti e trasmessi alla risorsa specificata; non presente un body nel messaggio di risposta.
PUT, richiede che lentit racchiusa nel messaggio di richiesta sia memorizzata nellURI indicato. Nel caso in cui lURI punti ad una risorsa
gi esistente questultima sar sostituita dalla nuova, altrimenti ne verr
creata una nuova.
In caso di creazione di una nuova risorsa, lorigin server deve necessariamente informare lo user agent mediante codice 201 CREATED. Se una
risorsa preesistente stata modificata il codice di risposta dovr essere
200 OK oppure 204 NO CONTENT.
Nel caso in cui una risorsa non possa essere correttamente creata o modificata presso lURI indicato nella richiesta, il server deve comunicare un
opportuno messaggio di errore che rifletta la natura del problema.
La differenza fondamentale fra POST e PUT risiede nella diversa interpretazione data allURI. Questo nel caso del metodo POST identifica la
risorsa che gestir lentit inclusa nella richiesta, mentre nel metodo PUT
esso identifica la risorsa stessa su cui si andr ad operare (e, di conseguenza, il server non potr applicare la richiesta a qualche altra risorsa
differente da quella indicata nellURI).
PUT idempotente ma non sicuro, non offre alcuna garanzia in termini
di controllo degli accessi o locking.
DELETE, richiede che lorigin server elimini la risorsa indicata nellURI.
Il client non pu essere certo che loperazione sia andata a buon fine poich
si tratta di un metodo che possibile modificare (override) manualmente
sulla macchina server.
TRACE, adoperato per invocare un messaggio di loop - back del
messaggio di richiesta. Tale metodo permette al client di osservare cosa
effettivamente ricevuto al termine della catena di richiesta ed effettuare,
di conseguenza, valutazioni prestazionali e testing.
CONNECT, adoperato mediante connessione proxy e permette di effettuare lo switching in un tunnel 17 .
Header Gli header di un messaggio di richiesta vengono acclusi dal client per
specificare informazioni sulla richiesta e su s stesso al server. Essi sono:
User - agent, una stringa che descrive il client che origina la richiesta;
tipicamente contiene
17 Tecnica utilizzata nel campo della trasmissione di dati digitali per veicolare informazioni
che normalmente utilizzano altri protocolli, attraverso lo standard HTTP (creando cio un
"tunnel" attraverso la connessione Http). Tale tecnica viene utilizzata anche per bypassare i
firewall, utilizzando tipologie di connessioni non bloccate per effettuare altre operazioni che
normalmente verrebbero filtrate.
32
tipo;
versione del browser;
sistema operativo;
Referer, consente di:
indicare lURL della pagina che ha condotto lutente alla nuova risorsa;
controllare i percorsi degli utenti al fine di operare politiche di user
profiling 18 o pubblicit.
Nel caso in cui una risorsa sia richiesta senza lutilizzo di link tale header
non deve essere trasmesso.
Dovrebbe chiamarsi Referrer ma la dizione attuale deriva da una impropria compitazione (spelling) effettuata nel 1996 da parte dellinformatico
Phillip Hallam - Baker che appose la parola priva della doppia r nel
RFC1945. Lerrore rimasto incorretto poich allepoca lo Unix spell
checker non riconosceva come parole di senso compiuto sia REFERER
che REFERRER;
Host, presenta le seguenti caratteristiche:
nome di dominio e porta a cui viene fatta la connessione;
obbligatorio in HTTP 1.1;
permette di effettuare il multi - homing (detto anche name - based
virtual hosting poich non richiede manipolazioni del routing o
multi - addressing IP ). Se un server contiene pi siti Web per scopi
diversi, Host consente al server di distinguere il sito a cui la richiesta
fa riferimento;
From, indica la e - mail del richiedente. Si richiede che lutente dia la
sua approvazione prima di inserire questo header nella richiesta;
Authorization, Proxy - Authorization, indica una stringa di autorizzazione per laccesso ad una risorsa;
Range, richiede non lintera risorsa ma solo una sua parte specificata come
una sequenza di byte range (vd. Fig. 16). E adoperato principalmente dai
download manager per riprendere download interrotti senza recuperare la
totalit del file in scaricamento;
Accept, Accept - Charset, Accept - Encoding, Accept Language,
indicano limplementazione della negoziazione del formato per ci che
riguarda, rispettivamente:
tipo MIME;
codice caratteri;
codifica MIME;
lingua umana.
33
Figura 16: Esempio di richiesta con header Range

Il client nella richiesta specifica cosa sia in grado di accettare e il server
nella risposta offre il match pi consono. E presente un quality factor
tramite cui possibile comunicare il valore di preferenza mediante numeri
reali compresi fra 0 (preferenza minima) ed 1 (preferenza massima, valore
predefinito).
Ad esempio la figura 17 comunica al server quanto segue: "Preferisco
text/html e text/x-c, ma se non esistono mandami la risorsa in formato
text/x-dvi, e se non esiste mandamela in formato text/plain"
Figura 17: Esempio di richiesta con header Accept

If-Modified-Since, If-Unmodified-Since, si tratta di richieste condizionali (cfr. sez. 3.5.9) nelle quali il metodo HTTP eseguito solo
se la condizione risulta vera (vd. 18). Possono verificarsi le seguenti
eventualit:
se la richiesta, a meno della condizione, d luogo ad una risposta
diversa dallo status 200 (OK), o la data non valida, questi header
sono ignorati;
se la richiesta, a meno della condizione, d luogo ad una risposta con
status 200 (OK) e la risorsa stata modificata, la risposta 200
(OK) e la risorsa inviata nel body;
se la richiesta, a meno della condizione, d luogo ad una risposta con
status 200 (OK) e la risorsa non stata modificata, la risposta
304 (Not Modified) e non inviato il body.
Figura 18: Esempio di richiesta con header If-Modified-Since
3.5.10
HTTP: Response message
Status code E un numero di tre cifre, di cui:

la prima indica la classe;
le altre due la risposta specifica.
18 Informazioni
associate ad uno specifico utente. Un profilo si riferisce, quindi, alla esplicita

rappresentazione digitale dellidentit di una persone e pu essere adoperato da sistemi che
tengano conto delle preferenze del soggetto stesso.
34
Figura 19: Esempio di richiesta

Esistono le seguenti classi:
1xx: Informational , indica una risposta temporanea alla richiesta,
durante il suo svolgimento;
2xx: Successful , indica che il server ha ricevuto, capito e servito la
richiesta;
3xx: Redirection, indica che il server ha ricevuto e capito la richiesta,
ma sono necessarie altre azioni da parte del client per portarla a termine;
4xx: Client error , indica che la richiesta del client non pu essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non
autorizzata);
5xx: Server error , indica che la richiesta pu anche essere corretta, ma
il server non in grado di soddisfare la richiesta per un problema interno
(suo o di applicazioni CGI19 ).
Reason phrase Ciascuno status code accompagnato da una descrizione per
esteso del messaggio da comunicare al client. Alcuni esempi sono:
100 Continue, se il client non ha ancora mandato il body;
200 Ok, se la GET avvenuta con successo;
201 Created, se il PUT stato effettuato con successo;
301 Moved permanently, se lURL non valido e il server conosce la
nuova posizione;
400 Bad request, se vi un errore sintattico nella richiesta;
401 Unauthorized, se manca lautorizzazione per accedere ad una risorsa;
403 Forbidden, se la richiesta non autorizzabile;
19 In
informatica Common Gateway Interface, una tecnologia standard usata dai web
server per interfacciarsi con applicazioni esterne generando contenuti web dinamici. Ogni
volta che un client richiede al web server un URL corrispondente ad un documento in puro
HTML gli viene restituito un documento statico (come un file di testo); se lURL corrisponde
invece ad un programma CGI, il server lo esegue in tempo reale, generando dinamicamente
informazioni per lutente.
35
404 Not found, se lURL errato;

500 Internal server error, rappresenta, tipicamente, un bug in un CGI;
501 Not implemented, se il metodo richiesto non conosciuto dal
server.
Header Gli header della risposta sono posti dal server per specificare informazioni sulla risposta e su s stesso al client. Nel dettaglio essi sono:
Server, stringa che descrive il server indicandone
tipo;
sistema operativo;
versione.
Accept - ranges, specifica che tipo di range pu accettare. I valori
previsti sono:
byte, opzionale. I client possono generare richieste di tipo byte range senza aver ricevuto questo header ;
none, vieta al client di inoltrare richieste di tipo range.
WWW-Authenticate, vedi sez. 3.5.11
3.5.11
HTTP: Authentication
Quando si vuole accedere ad una risorsa sulla quale vigono restrizioni di accesso, il server richiede lautenticazione dellutente. Al metodo GET fornita la
risposta 401 (Unauthorized), pi un header WWW - Authenticate che
specifica i criteri con cui autenticarsi. HTTP ha due metodi di autenticazione:
Basic access authentication (introdotto in HTTP 1.0) e Digest access
authentication (introdotto in HTTP 1.1).
Basic access authentication Lautenticazione basic basata sullinvio, da
parte del client, di una user-ID e di una password per ciascun realm 20 . Il server
esaudir la richiesta solo se user-ID e password risultano essere validi per lo
specifico spazio di protezione dellURI richiesto. Nello specifico lautenticazione
basic si articola nelle seguenti fasi:
il client effettua una richiesta ad un server ;
il server risponde con lheader WWW-Authenticate contenente il realm;
il client richiede le informazioni di autorizzazione;
il client crea una nuova richiesta GET nella quale fornisce le informazioni
di autenticazione codificate in Base64(vd. 3.5.4);
20 Lattributo realm (case insensitive) richiesto per tutte quelle forme di autenticazione
che richiedano il cosiddetto challenge (protocolli basati su domanda - risposta). Il valore
del realm (case sensitive) definisce lo spazio di protezione. Lutilit dei realm consiste nella
possibilit di partizionare le risorse su un server in tanti sottoinsiemi ciascuno dotato di propri
meccanismi di autenticazione. Il valore del realm una stringa, assegnata, generalmente,
dallorigin server.
36
il browser continuer ad inviare il medesimo header per tutte le pagine

dello stesso realm.
Non esistono parametri di autenticazione opzionali.
Il problema principale di tale approccio che la password transita in chiaro
sulla rete. (Fig. 20)
Figura 20: Esempio di challenge con basic authentication
Digest access authentication E un meccanismo di autenticazione introdotto in HTTP 1.1. La caratteristica innovativa di tale approccio che la password non transita in chiaro bens mediante una fingerprint (hash), calcolata
applicando lalgoritmo di criptazione MD5 (Message Digest 5).
Per evitare labuso della password, anche se crittografata, insieme alla fingerprint vengono codificate anche informazioni, come lo username, il realm, lURI
richiesto, un time stamp (nonce), etc.
Nel caso pi semplice (quality of protection qop = auth):
h1 = MD5(username:realm:password)
h2 = MD5(method:digestURI)
response = MD5(h1:nonce:h2)
3.6
Connessione HTTP
La connessione HTTP composta da una serie di richieste da parte del client

a cui fanno seguito altrettante risposte da parte del server.
3.6.1
HTTP 1.0
La connessione fra client e server avviene tramite instaurazione di una singola

connessione TCP per ciascun oggetto da trasferire. Si tratta, quindi, di connessioni non persistenti (Fig. 22). Un client pu chiedere luso di connessione
persistente con lheader field Connection: Keep-alive: se il server supporta
le connessioni persistenti, inserir il medesimo header field nella risposta.
37
Figura 21: Esempio di challenge con digest authentication

3.6.2
HTTP 1.1
In HTTP 1.1 per impostazione predefinita, le connessioni sono persistenti(Fig. 22). Se il server decide di chiudere la connessione, nella risposta inserir
lheader field Connection: Close. Sia i server sia i client adottano timeout
dopo i quali le connessioni aperte, rimaste inattive, vengono chiuse.
Figura 22: Esempio di connessione non persistente (multiple connection) e

persistente
Pipelining Il pipelining la trasmissione di pi richieste senza attendere

larrivo della risposta alle richieste precedenti (Fig. 23). Riduce ulteriormente
i tempi di latenza, ottimizzando il traffico di rete, soprattutto per richieste che
riguardano risorse molto diverse fra loro per dimensioni o tempi di elaborazione.
E fondamentale che le risposte vengano date nello stesso ordine in cui sono
state fatte le richieste poich HTTP non fornisce un meccanismo esplicito di
associazione o riordinamento.
38
Figura 23: Esempio di connessione no pipelining e pipelining
3.7
Gestione delle sessioni
HTTP stateless: non ha memoria della precedente richiesta. In alcuni tipi

di siti/applicazioni Web , tuttavia, necessario mantenere traccia delle richieste
precedenti al fine di creare una transazione o sessione utente, cio un intervallo
di tempo in cui un medesimo utente effettua una sequenza di accessi a risorse
di una determinata sezione del sito. In tali casi si deve ricorrere ad alcune
tecnologie per tener traccia della sessione; un esempio dato dai cookie.
3.7.1
Cookie
Un cookie una breve informazione scambiata tra il server ed il client(Fig. 24).

Il termine cookie (anche magic cookie) in informatica indica un blocco di dati
opaco (cio non interpretabile) lasciato in consegna ad un richiedente per poter
ristabilire in seguito il suo diritto alla risorsa richiesta (come il tagliando di una
lavanderia).
Si tratta di un piccolo file di testo locale esterno rispetto al paradigma di
HTTP adoperata come estensione di Netscape nellRFC 2109 e poi ancora nel
RFC 2965.
Il cookie identifica una sessione in corso (o uno stesso utente attraverso
connessioni successive).
Architettura di un cookie Alla prima richiesta di uno user-agent, il server
fornisce la risposta ed un header aggiuntivo, il cookie, con dati arbitrari, e con
la specifica di usarlo per ogni successiva richiesta.
Il server associa questi dati ad informazioni sulla transazione. Ogni volta che
lo user-agent acceder a questo sito, rifornir i dati del cookie che permettono
al server di identificare nuovamente il richiedente.
Questioni di sicurezza permettono di distinguere tra:
cookie spediti solo al server di appartenenza, adoperati per sessioni, transazioni e profilazione utenti;
cookie di terze parti, usati per la profilazione utenti da network pubblicitari.
39
I cookie usano due header, uno per la risposta ed uno per le richieste successive:
set-Cookie, header della risposta da parte di un server. Il client pu
memorizzarlo in un file testuale e rispedirlo alla prossima richiesta;
cookie, header della richiesta. Il client decide se spedirlo sulla base di:
URL della risorsa;
nome del server ;
et del cookie.
Figura 24: Esempio di cookie
Alternative ai cookie I cookie permettono al server di riassociare una richiesta a richieste precedenti (creare uno stato tra connessioni) attraverso luso
di un pacchetto di dati opaco.
Ci sono altri metodi, ma hanno tutti difetti:
si potrebbe associare lo stato allindirizzo IP del richiedente ma alcuni
computer sono multi-utente, quindi utenti diversi condividono lo stesso
IP; altri computer hanno indirizzi dinamici, e lo stesso IP pu essere
assegnato a computer diversi ;
si potrebbero nascondere informazioni allinterno della pagina HTML (attraverso campi nascosti di un form), ma questo significa dover generare
dinamicamente tutte le pagine ed essere soggetti a manipolazioni semplici
da parte degli utenti. Inoltre sono informazioni che rimangono associate
ad una pagina specifica (un back e ho perso il contenuto del mio carrello);
si potrebbero complicare gli URL della pagine, inserendo dentro le informazioni di stato, ma si complica la gestione dei proxy, delle cache, e si
rende pi facilmente manipolabile la stringa opaca.
40
Third - Party Cookies Un uso subdolo (ma alcuni lo giustificano) dei cookie
linserimento nei banner e nelle pubblicit. Questo permette al fornitore di
pubblicit via Web di seguire la navigazione di un utente attraverso tutti i siti a
cui fornisce banner, e quindi fornire una profilazione pi precisa del navigatore,
con effetti discutibili sulla sua privacy. LRFC 2965 esplicitamente proibisce
questo tipo di comportamento, lavvertenza per largamente ignorata. Si
aggiunga che alcune versioni di browser hanno bug che permettono a codice
Javascript malizioso, presente nelle pagine, di sniffare i contenuti dei cookie
destinati ad altri domini.
E recente la convenzione do not track tra produttori di browser e associazioni di fornitori di pubblicit via Web: lutente deve specificare nelle preferenze
del browser che non vuole essere tracciato (lopzione disattivata di default).
In tal caso, in ogni richiesta HTTP inserito lheader field sperimentale DNT:
1.
3.8
Proxy server
In generale un proxy si pone come intermediario tra client e server e stabilisce

se e come rispondere al client. Esistono due tipologie di proxy:
Proxy di cache, che gode delle seguenti caratteristiche:
risposte a richieste multiple agli stessi URL possono essere salvate in
una locazione intermedia per una maggiore efficienza nella gestione
delle risposte;
risiede, solitamente, sulla stessa LAN del client;
vantaggioso per bassi valori di cache miss.
Proxy di filtro, che gode delle seguenti caratteristiche:
esigenze di sicurezza o di controllo degli abusi di una rete possono
richiedere lesecuzione della richiesta solo in casi specifici;
in caso contrario viene fornito un messaggio di mancata autorizzazione;
uso di black list (domini non consentiti) o di white list (domini
consentiti).
Figura 25: Esempio di proxy server
41
3.8.1
Reverse proxy
Viene detto reverse proxy un proxy server che si pone da gateway nei confronti
di uno o pi Web server. I client contattano il reverse proxy come se fosse
lorigin server, senza sapere che la richiesta sar inoltrata al vero origin server.
Le finalit di impiego di tale tipologia di proxy sono le seguenti:
permettere a pi Web server di uscire su Internet con un unico indirizzo
IP pubblico;
load balancing, cio distribuire il carico tra diversi Web server ;
firewall;
caching;
Accelerazione hardware di primitive crittografiche necessarie per SSL/TLS.
Figura 26: Esempio di reverse proxy
3.9
Caching
Il caching una tecnica adoperata per la riduzione delle latenze e delloverhead

di rete 21 . Pu essere client-side, server-side (cache server ) o intermedia mediante limpiego di un proxy. La cache server-side riduce i tempi di computazione
di una risposta, ma non ha effetti sul carico di rete. Le altre, invece, riducono
il carico di rete.
HTTP 1.0 si basava su tre header per la gestione della cache:
expires, il server specifica la data di scadenza di una risorsa;
pragma:no-cache, fornita dal server, istruisce il client di non fare cache
della risorsa in ogni caso;
If-Modified-Since, il client richiede la risorsa solo se modificata dopo
una certa data. Richiede una gestione del tempo comune tra client e
server.
HTTP 1.1 permette due tipi di controllo di cache:
Server-specified expiration, il server stabilisce una data di scadenza
della risorsa, con lheader Expires o con la direttiva max-age nellheader
Cache-Control. Nel dettaglio:
21 Informazioni addizionali accluse ad ogni file trasmesso in rete e contenenti, ad esempio,
campi di sorgente e destinatario, delimitatori del pacchetto, campi di controllo errore
42
se la data di scadenza gi trascorsa, la richiesta deve essere riconvalidata. Se il client accetta anche risposte scadute, o se lorigin
server non pu essere raggiunto, il cache server pu rispondere con
la risorsa scaduta insieme allo status code 110 (Response is stale);
se Cache-Control specifica la direttiva must-revalidate, la risposta
scaduta non pu mai essere rispedita. In questo caso il cache server
deve riprendere la risorsa dallorigin server. Se questo non risponde,
la cache mander un codice 504 (Gateway time-out);
se Cache-Control specifica la direttiva no-cache, la richiesta deve
essere fatta sempre allorigin server ;
Heuristic expiration, il gestore della cache stabilisce valori euristici
di durata delle risorse, dopo i quali assume che siano scadute. HTTP
suggerisce, ad esempio, di basarsi sulla data di ultima modifica e applicare
un fattore moltiplicativo
expiry-period = time-since-last-modified-date * factor
expiry-date = current-date + expiry-period
valore tipico: factor = 0.1
per cui, se al momento della richiesta una risorsa non stata modificata
da 10 ore, sar considerata valida ancora per 1 ora.
Queste assunzioni possono a volte essere ottimistiche, e risultare in risposte
scorrette. Se non valida con certezza, una risposta assunta come valida
deve fornire un codice 113 (Heuristic expiration) al client.
3.9.1
Convalida della risorsa in cache
Anche dopo la scadenza, nella maggior parte dei casi, una risorsa non viene
modificata sullorigin server e quindi la risorsa in cache continua a risultare
valida. Modi semplici per fare convalida da parte di un cache server sono i
seguenti:
usare HEAD, viene, cio, inoltrata una richiesta e verificata la data di
ultima modifica (comporta una richiesta preliminare supplementare);
fare una richiesta condizionale, cio, se la risorsa stata modificata, viene
regolarmente fornita la nuova risorsa, altrimenti viene fornita la risposta
304 (Not modified ) senza body della risposta. Questo riduce il numero di
richieste.
Convalidatori (validators) Gli Entity Tag (ETag) sono un altro meccanismo per convalidare le risorse (entity) in cache. Lorigin server inserisce
nella sua risposta iniziale un header field con il/i tag associato/i alla versione
restituita della risorsa.
43
Poich sia lorigin server che le cache comparano due validatori per decidere
se rappresentano le stesse entit o differenti, ci si aspetterebbe che, nel caso in
cui lentit cambi anche il validatore cambi. Se questo accade allora parliamo
di strong validator.
Nel caso in cui un server preferisca cambiare il validatore solo se avvengono
significativi cambiamenti semantici utilizzabile un validatore che non cambi
ogni volta in cui la risorsa cambia: si definisce weak validator.
Successivamente, il client pu effettuare una richiesta condizionale usando
uno degli header
If-Match: lista entity tag
Match: esegui il metodo HTTP;
No match: 412 Precondition Failed.
If-None-Match: lista entity tag
Match:
se GET o HEAD, allora 304 Not Modified ;
se altro metodo, allora 412 Precondition Failed.
No match: esegui il metodo HTTP.
3.10
Modelli di sicurezza
Ci sono due modi per fornire una comunicazione sicura (cio non intercettabile
da orecchie maliziose durante la trasmissione):
usare uninfrastruttura di trasporto sicura. Il protocollo applicativo non
cambia, ma ogni pacchetto trasmesso nello scambio di informazioni viene
gestito in maniera sicura dal protocollo di trasporto;
usare un protocollo sicuro a livello applicazione. Si usa un protocollo
diverso, che si occupa di gestire la trasmissione sicura delle informazioni.
Esempi di protocolli sicuri sono:
HTTPS (RFC 2818), introdotto da Netscape, trasmette i dati in HTTP
semplice su un protocollo di trasporto (TLS, Transport Layer Security);
successore di SSL, (Secure Sockets Layer ) crittografa tutti i pacchetti. Il
server ascolta su una porta diversa (per default la porta 443), e si usa uno
schema di URI diverso ( https:// );
S-HTTP (RFC 2660), poco diffuso, incapsula richieste e risposte HTTP
in un messaggio crittografato secondo o un formato MIME apposito (MIME Object Security Services, MOSS), o un formato terzo (Cryptographic
Message Syntax, CMS). E pi efficiente ma complesso.
44
Figura 27: Esempio di TLS

TLS Garantisce integrit e privatezza delle comunicazioni Si basa su PKI
(Public Key Infrastructure) per lautenticazione e la crittografia. I certificati
X.509 sono rilasciati da Certification Authorities fidate. La crittografia asimmetrica (chiave pubblica-chiave privata) durante lhandshake. La crittografia
simmetrica (es. AES) successivamente per i dati. Client e server negoziano gli
algoritmi di cifratura da usare e se effettuare autenticazione solo del server o
mutua. Versioni successive adottano algoritmi di cifratura sempre pi robusti.
TLS 1.0 supportato da tutti i maggiori browser. TLS 1.1 solo da IE 8+,
Opera 10+ e Chrome 22+. TLS 1.2 solo da IE 8+ e Opera 10+.
Apache HTTP Server
Apache un Web server realizzato da Apache Software foundation per la prima

volta nel 1995 (prima versione ufficiale 0.6.2).
Esso implementa il protocollo HTTP 1.1, un progetto open source disponibile con licenza free software (Apache License) 22 ed disponibile per differenti
sistemi operativi (Windows, Netware, OS/2 e UNIX-like).
22 Come ogni licenza di software libero, la licenza Apache consente agli utenti di usare il
software per ogni scopo, di distribuirlo, modificarlo e di distribuire versioni modificate di esso.
La Licenza Apache non richiede che versioni modificate del software siano distribuite secondo i termini della stessa licenza o come software libero: essa richiede solo che si includa
uninformativa del fatto che si utilizzato software licenziato secondo i termini della Licenza
Apache.
Quindi, a differenza di quanto accade con le licenze copyleft, gli utenti di versioni modificate
del software licenziato secondo i termini della Licenza Apache non godono necessariamente
delle suddette libert. O, considerando la situazione dal punto di vista del licenziatario, esso
ha la libert di utilizzare il software in ogni modo, anche in prodotti proprietari, a danno degli
utilizzatori.
I due file che devono essere inclusi nella directory principale dei prodotti software distribuiti
sono:
LICENSE, una copia della licenza;
45
4.1
Installazione nei S.O. Windows
Per i sistemi operativi Windows disponibile un pacchetto dinstallazione MSI

con procedura guidata.
Figura 28: Esempio di interfaccia MSI per Apache
4.2
Installazione nei S.O. UNIX-like
Linstallazione in ambiente Linux si effettua con pacchetti precompilati (RPM,

DEB) o per compilazione di sorgenti. Di seguito i passi da seguire:
scaricare i sorgenti di Apache da http://httpd.apache.org/ (es. larchivio httpd-2.4.3.tar.bz2);
decomprimere larchivio con il comando tar
$ tar -xjvf httpd-2.4.3.tar.bz2 ;
portarsi nella directory dei sorgenti
$ cd httpd-2.4.3 ;
preparare la compilazione
$ ./configure enable-so prefix=[INSTALL_DIR]
NOTICE, uninformativa testuale che elenca i nomi delle librerie licenziate che sono
utilizzate, con i nomi degli sviluppatori.
Nel codice redistribuito si deve preservare in ogni file licenziato qualsiasi informativa di diritto dautore e di brevetti presente ed in ogni file modificato si deve aggiungere uninformativa
specificando che il file stato modificato.
46
dove prefix indica il percorso della directory dinstallazione, ad esempio

$ ./configure enable-so prefix=/usr/local/httpd ;
effettuare la compilazione
$ make;
installare il programma compilato (come utente root)
$ make install.
Figura 29: Struttura predefinita della directory
4.3
Avvio del server
Se linstallazione andata a buon fine, possiamo avviare il server con il comando

apachectl. Esso un front end al server Apache. E utile allamministratore
per controllare il funzionamento del daemon httpd.
Lo script pu operare in due differenti modalit:
pass-through mode, semplice front-end che si occupa di impostare le
variabili dambiente necessarie allesecuzione e, successivamente, invoca
lhttpd passando gli eventuali argomenti della command line
apachectl [ httpd-argument ] ;
Di seguito tutti i comandi disponibili:
-d serverroot, imposta il valore iniziale per la direttiva serverroot.
Il valore di default /usr/local/apache2 ;
-f config, usa le direttive contenute nel file config. Il valore di default
conf/httpd.conf ;
47
-k start|restart|graceful|stop|graceful-stop, Signals httpd to start,

restart, or stop. See Stopping Apache httpd for more information.
-C directive, processa le direttive di configurazione prima di leggere
i file di configurazione;
-c directive, processa le direttive di configurazione dopo aver letto
i file di configurazione;
-D parameter, imposta un parametro di configurazione che pu
essere usato nelle sezioni IfDefine presenti nei file di configurazione
al fine di skippare condizionalmente comandi in fase di avvio o riavvio;
-e level, imposta il LogLevel in faso di avvio. E utile per incrementare la verbosit dei messaggi di errori;
-E file, invia messaggi di errorSend in fase di avvio del server ad un
file;
-R directory, quando il server compilato utilizzando la SHAREDCORE rule23 , tale direttiva specifica la directory per gli oggetti
condivisi;
-h, restituisce un breve riassunto delle opzioni della riga di comando
disponibili;
-l, restituisce un elenco di tutti i moduli compilati nel server fatta
eccezione per i moduli inclusi adoperando la direttiva LoadModule;
-L, restituisce la lista di tutte le direttive assieme agli argomenti e i
"luoghi" in cui la direttiva stessa valida;
-M, salva una lista dei moduli, statici e dinamici, caricati;
-S, mostra le impostazioni cos come apprese dal file di configurazione;
-T (dalla versione 2.2.17 in poi), salta il controllo del root in fase
di avvio o riavvio;
-t, avvia il test sintattico per il solo file di configurazione. Il programma esce immediatamente al termine del test con codice 0 (Syntax
OK ) o codice diverso da 0 (Syntax Error );
-v, stampa la versione di httpd ed in seguito esce;
-V, stampa la versione e i parametri di building di httpd ed in seguito
esce;
-X, avvia httpd in debug mode. The following arguments are available
only on the Windows platform:
-k install|config|uninstall (solo per piattaforma Windows),
rispettivamente, installa Apache httpd come servizio di Windows
NT, modifica le opzioni di avvio del servizio httpd e disinstalla il
servizio httpd ;
-n name, il nome da segnalare per il servizio httpd ;
23 Sulle direttive Unix moderne esiste un meccanismo di linking dinamico denominato Dynamic Shared Objects (DSO) che permette di effettuare il building di un pezzo di programma
in uno speciale formato per caricarlo a run-time nello spazio degli indirizzi del programma. I
vantaggi risiedono nella possibilit di adoperare facilmente package di terze parti. Tutto ci
a prezzo di prestazioni velocistiche ridotte in fase di avvio ed esecuzione del server.
48
-w, mantiene aperta la finestra di comando in caso di errore cos da

poter leggere eventuali messaggi di errore.
SysV init mode, agisce da script SysV, prendendo in ingresso argomenti
costituiti da una singola parola come start,restart e stop, traducendoli
in appropriati segnali da inviare al demone
apachectl command
Di seguito tutte le word adoperabili:
start, avvia il daemon httpd. Restituisce un errore se gi in esecuzione. E del tutto equivalente allargomento da riga di comando -k
start;
stop, interrompe il daemon httpd. E del tutto equivalente allargomento da riga di comando -k stop;
restart, riavvia il daemon httpd. Se il daemon non in esecuzione
allora lo avvia. E del tutto equivalente allargomento da riga di
comando -k restart;
fullstatus, mostra un riassunto dello stato corrente dal mod_status. Affinch sia adoperabile necessario avere mod_status attivato sul server e un text-based browser come lynx. LURL da adoperare per accedere al report configurabile settando la variabile
STATUS_URL nello script;
status, fornisce un resoconto sintetico dello stato attuale (omette
la lista delle richieste correntemente servite rispetto al precedente
comando);
graceful, riavvia il daemon httpd. E del tutto equivalente allargomento da riga di comando -k graceful ;
graceful-stop, interrompe lesecuzione del daemon httpd. Differisce
dal normale stop poich le connessioni attualmente aperte non sono
annullate. E del tutto equivalente allargomento da riga di comando
-k graceful-stop;
configtest, avvia un test sul file di configurazione. E del tutto
equivalente allargomento da riga di comando -t;
startssl (opzione presente solo nelle primissime versioni ed in seguito
eliminata), avvia httpd con supporto SSL.
apachectl restituisce, come valori di uscita, 0 come successo e un numero
> 0 in presenza di errori.
$ [INSTALL_DIR]/bin/apachectl -k start
Lo script apachectl imposta alcune variabili dambiente necessarie e avvia
il programma httpd, il vero e proprio server. httpd rimane in esecuzione
come daemon (processo sempre attivo fino allarresto, distaccato dai terminali
di shell ) apachectl passa a httpd tutti i parametri che forniamo.
Se non appaiono messaggi di errore, collegandosi con il browser a http://localhost/ dovremmo vedere una pagina HTML che testimonia che il server HTTP
in funzione.
49
Figura 30: Corretta installazione del server Apache
4.4
Avvio come servizio di sistema
Per avviare il server HTTP come servizio di sistema, occorre aggiungere la

chiamata ad apachectl in uno degli script di avvio del sistema tipicamente
in /etc/init.d/, /etc/rc.local o un file in una delle directory /etc/rc.N. In tal
modo il web server eseguito con i privilegi di root: occorre, per, configurare
opportunamente le restrizioni di accesso e le opzioni di sicurezza per evitare
potenziali rischi.
In Windows linstallazione guidata imposta automaticamente il web server
come servizio di sistema.
4.5
Configurazione
Allavvio, httpd esamina il file [INSTALL_DIR]/conf/httpd.conf che contiene

le impostazioni di configurazione. Il file httpd.conf costituito da un elenco
di direttive. Esse possono essere di due tipi:
semplici, se poste su una sola riga.
Timeout 300
composte, se poste su pi righe e racchiudono altre direttive.
<Directory dir>
...
</Directory
Le righe che iniziano per # sono di commento e, dunque, non vengono prese
in considerazione.
50
4.6
Direttive di base
Le direttive di base adoperabili sono:

ServerRoot Indica la directory principale di Apache, sotto la quale si
trovano i file di configurazione, log ed errore del server. Per impostazione
predefinita coincide con il PREFIX24 indicato durante linstallazione.
ServerRoot "/usr/local/httpd"
Listen Indica su quale indirizzo IP e su quale porta il server deve mettersi
in ascolto. Se non specificato un indirizzo, si metter in ascolto su tutti
gli indirizzi IP posseduti dal calcolatore (uno per ogni interfaccia di rete
connessa). Per impostazione predefinita la porta la numero 80.
Listen IP[:port] Listen port
ServerAdmin Indirizzo email che il server inserisce nei messaggi di errore
inviati ai client (per poter contattare lamministratore del server ).
ServerAdmin email-address
DocumentRoot Indica la directory che contiene i documenti da servire
ai client. Limpostazione predefinita [INSTALL_DIR]/htdocs. Unimpostazione molto comune
DocumentRoot "/usr/local/httpd/htdocs"
DocumentRoot "/var/www/html"
ServerName Imposta schema, hostname e porta che il server user per
identificarsi quando si creano URL per la ridirezione.
ServerName www.example.com:80
DefaultType Tipo MIME (Multipurpose Internet Mail Extensions) predefinito per le risorse fornite dal server. E usato quando Apache non in
grado di determinare il tipo MIME di una risorsa in base al nome del file
o ad altre sue propriet.
DefaultType MIME-type DefaultType application/octet-stream DefaultType
text/plain
24 Percorso
adoperato in fase di installazione.
51
TimeOut Secondi che il server attender prima di interrompere una connessione se la trasmissione TCP si blocca durante la ricezione di una
richiesta o linvio di una risposta.
TimeOut 300
KeepAlive Connessioni TCP persistenti (richiesta di pi file con la stessa
connessione). Default in HTTP/1.1, riduce la latenza nellinvio di pagine
con file collegati (immagini, etc.).
KeepAlive On|Off
KeepAliveTimeout Secondi che il server attender ulteriori richieste su
una connessione TCP aperta.
KeepAliveTimeout 5
4.7
Moduli
Apache HTTP Server dotato di numerosi moduli che forniscono funzionalit

aggiuntive. Ve ne sono di due tipi:
compilati staticamente (durante linstallazione) e caricati ad ogni avvio
di httpd;
caricati dinamicamente come librerie condivise; per caricare un modulo
dinamicamente occorre inserire nel file httpd.conf una direttiva LoadModule, specificando:
module, nome del modulo
file, percorso del file della libreria condivisa (estensione .dll in Windows, .so in Linux) relativo a ServerRoot.
I moduli principali sono:
mod_alias, permette di creare alias e ridirezioni;
mod_authXXX, set di moduli che implementano diverse tecniche per
lautenticazione e lautorizzazione dei client;
mod_cache, per la gestione della cache;
mod_cgi, permette di eseguire script CGI (Common Gateway Interface)
per generare dinamicamente i contenuti;
mod_include, permette di eseguire istruzioni server-side include 25 ;
25 I comandi Server Side Include (SSI) sono istruzioni inserite allinterno del codice
sorgente delle pagine HTML. A differenza dei normali tag, i comandi SSI non visualizzano
nulla, ma eseguono delle istruzioni e ne includono loutput nella pagina contenente il codice.
La sintassi di base del SSI :
<!#comando parametro="valore o lista di valori">.

I comandi sono posizionati allinterno dei commenti HTML (<! commento >) cos se SSI
non abilitato, gli utenti non vedranno i comandi SSI nelle pagine, finch non guarderanno il
codice della pagina. Nota: lestensione base per le pagine contenenti codice SSI .shtml
52
mod_log_config, permette di personalizzare il formato dei log;

mod_ssl, abilita la crittografia mediante i protocolli SSL (Secure Sockets Layer) e TLS (Transport Layer Security);
mod_userdir, permette agli utenti del sistema in cui eseguito Apache
di avere una directory personale sul web server.
4.8
Server-side include
Semplice linguaggio per la generazione di pagine Web dinamiche, interpretato

direttamente dal Web server (senza ricorrere ad interpreti esterni come per i
linguaggi di server-side scripting PHP, ASP, JSP, Perl, etc.)
Le pagine HTML che contengono SSI devono avere estensione .shtml o
.shtm.
SSI si basa sullinserimento nella pagina HTML di istruzioni con sintassi
<!#instruction parameter=value parameter=value ... >
Le istruzioni principali sono:
includere nella pagina il contenuto di un file di testo;
<!#include virtual="header.html" > <!#include file="parte1.txt" >
includere nella pagina loutput di un CGI o di un comando di shell ;
<!#exec cgi="/cgi-bin/calcola.cgi" > <!#exec cmd="ls -l" >
istruzioni di controllo #if, #elif, #else, #endif (condizioni su variabili
dambiente o valutazione di espressioni)
4.9
Direttiva IfModule
Permette di specificare un insieme di direttive solo se un modulo di Apache

caricato
<IfModule mod> ... </IfModule>
Ad esempio:
<IfModule dir_module>
DirectoryIndex index.html index.htm index.php
</IfModule>
Se lURL della richiesta di un client corrisponde a una directory, indica quale

documento (allinterno di tale directory) inviare al client. La direttiva ha valore
solo se stato caricato il modulo dir_module.
53
4.10
Log degli errori
ErrorLog indica il percorso del file di log degli errori (relativo a ServerRoot)
ErrorLog file ErrorLog logs/error_log
LogLevel controlla la tipologia di messaggi inviati al log degli errori. Esistono differenti valori possibili di level (dal meno grave al pi grave):
debug, messaggi di debug;
info, informazione;
notice, condizione normale ma significativa;
warn, condizione di warning;
error, condizione di errore;
crit, condizione critica;
alert, unazione deve essere immediatamente presa;
emerg, emergenze - il sistema non adoperabile.
Ad esempio:
LogLevel warn.
4.11
Log degli accessi
LogFormat, se caricato il modulo log_config_module, permette di definire

un formato personalizzato per il log degli accessi
LogFormat format nickname dove:
format, indica una stringa di formato del log;
nickname, indica la denominazione del nuovo formato.
CustomLog applica al log degli accessi un formato personalizzato
CustomLog file nickname | format
dove:
file, indica il percorso per il file di log (relativo a ServerRoot).
Ad esempio:
<IfModule log_config_module>
54
%u %t %r
%>s
LogFormat %h
%bmylog
CustomLog logs/access_log mylog

</IfModule>
Risultato in logs/access_log:
192.168.33.1 - [19/Nov/2006:21:36:51 +0100] "GET / HTTP/1.1" 200 44
4.12
Direttive per le directory
Directory, decide quali servizi e opzioni abilitare o disabilitare, per ciascuna

directory a cui il server pu accedere. Per ragioni di sicurezza:
dapprima si configura un insieme ristretto di opzioni di default;
poi si specifica quali funzionalit aggiuntive abilitare in una particolare
directory;
directory-path il percorso della directory; pu contenere espressioni regolari
per far riferimento a un insieme di directory in ununica voce.
Le opzioni applicate si estendono automaticamente alle sottodirectory
<Directory directory-path> Options ... AllowOverride ... Order ... Deny ...
| Allow ... </Directory>
Options, indica le opzioni abilitate. Le principali opzioni possibili sono:

All, (impostazione predefinita) tutte le opzioni sono abilitate tranne MultiViews;
ExecCGI: permette lesecuzione di CGI;
FollowSymLinks, il server seguir i link simbolici in questa directory.
Ci permette di servire documenti che risiedono al di fuori della directory
specificata da DocumentRoot;
Includes, consente di adoperare i server-side include (SSI);
Indexes, se lURL della richiesta di un client corrisponde a una directory,
e non definita una pagina predefinita per quella directory mediante la
direttiva DirectoryIndex, il server invier un listato dei contenuti della
directory;
55
MultiViews, permette la content negotiation (negoziazione dei contenuti) come previsto da HTTP 1.1.
AllowOverride controlla quali direttive possono essere inserite nei file .htaccess.
Order, Allow e Deny controllano laccesso alle risorse dal server:
Order Deny,Allow, accesso consentito a tutti tranne i client indicati
nelle direttive Deny (politica black list);
Order Allow,Deny, accesso vietato a tutti tranne i client indicati nelle
direttive Allow (politica white list);
Deny from all, vieta laccesso a tutti;
Deny from domain, vieta laccesso ai client appartenenti al dominio
DNS specificato;
Allow from all, consente laccesso a tutti;
Allow from domain, consente laccesso ai client appartenenti al dominio.
Tipiche opzioni di default: <Directory /> Options FollowSymLinks Allo-
wOverride None Order Deny,Allow Deny from all </Directory>
Opzioni per una particolare directory:

<Directory "/usr/local/httpd/htdocs/music"> Options +Indexes -FollowSymLinks
Order Deny, Allow Deny from poliba.it </Directory>
Il segno + indica unopzione abilitata in pi rispetto alle impostazioni di

default specificate prima. Il segno - indica unopzione disabilitata rispetto alle
impostazioni di default specificate prima.
4.13
Direttiva per i file
FilesMatch consente di applicare alcune direttive ai file il cui nome corrisponde

a una data espressione regolare
<FilesMatch regexp> ... </FilesMatch>
56
Ad esempio si pu impedire ai client di vedere i file il cui nome inizia con un

punto
<FilesMatch "
."> Order deny,allow Deny from all </FilesMatch>
4.14
Ridirezione
Redirect Permette di informare i client che una risorsa ha cambiato posizione

allinterno del server. Il client far una nuova richiesta della risorsa alla nuova
posizione.
La sintassi la seguente
Redirect type path URL
dove:
type, indica il tipo di reindirizzamento (da esso dipende il codice di stato
HTTP inviato ai client) che pu essere
permanent: risorsa spostata permanente;
temp: risorsa spostata temporaneamente ( il tipo predefinito);
seeother: la risorsa stata sostituita;
gone: risorsa eliminata (in questo caso il parametro URL si omette);
path: percorso delle risorse da reindirizzare; inizia con uno slash. Tutte
le risorse sul server il cui percorso inizia con il path indicato subiranno il
reindirizzamento;
URL: nuova posizione delle risorse. Deve essere un URL completo di
schema, hostname e percorso.
Esempio per il server www.example.com Redirect permanent /olddir http://www.example.com/newdir
Una richiesta a http://www.example.com/olddir/mydoc.html sar reindirizzata a http://www.example.com/newdir/mydoc.html.
IMMAGINE!!!!!
4.15
Alias
Alias, mappa un percorso web con un percorso sul filesystem del server. Si
usa per permettere laccesso a risorse che risiedono al di fuori della directory
DocumentRoot.
La sintassi la seguente Alias URL-path directory-path dove:
URL-path, indica il percorso web da mappare;
57
directory-path, indica il percorso completo della directory destinazione

nel filesystem del server. Solitamente occorre definire anche una direttiva Directory per definire opzioni e modalit daccesso per la directory
destinazione.
Ad esempio per il server www.example.com Alias /cooking/ /opt/recipes/
la richiesta di http://www.example.com/cooking/italian/pizza.html recuperer il documento situato in /opt/recipes/italian/pizza.html nel filesystem del
server.
A differenza del reindirizzamento, un alias trasparente ai client.
4.16
Messaggi derrore personalizzati
ErrorDocument, definisce un messaggio derrore HTTP personalizzato. La

sua sintassi ErrorDocument code document
dove:
code, codice di errore HTTP;
document, messaggio da mostrare agli utenti. Esso pu essere:
una stringa di testo (tra virgolette);
il percorso (relativo a DocumentRoot) di un file HTML;
un URL assoluto di un file HTML.
Esempi sono i seguenti: ErrorDocument 500 "Ci dispiace tanto, ma il server
ha incontrato un errore inatteso". ErrorDocument 404 /notfound.html. ErrorDocument 404 /cgi-bin/notfound.pl. ErrorDocument 403 http://www.example.com/forbidden.html.
4.17
Directory personali degli utenti
UserDir, viene resa accessibile la directory dir nella home directory di ciascun utente in un percorso di URL contenente il nome utente preceduto da un
carattere (tilde).
La sua sintassi la seguente UserDir dir.
Ad esempio se bob un utente del sistema www.example.com e nel file
httpd.conf presente la direttiva la richiesta HTTP con URL http://www.example.com/ bob/biography.html ricever in risposta il documento memorizzato in
/home/bob/public_html/biography.html
Le opzioni adoperabili sono:
UserDir enabled|disabled abilita o disabilita le directory personali per tutti
gli utenti
UserDir enabled|disabled user1 user2 ... userN abilita o disabilita le directory personali di alcuni utenti
58
Normalmente si disabilita per tutti gli utenti tranne quelli a cui fornire
esplicitamente lo spazio personale.
UserDir public_html UserDir disabled UserDir enabled alice bob peter
E opportuno associare una direttiva Directory per definire le opzioni abilitate o disabilitate nelle directory personali degli utenti e il controllo daccesso.
Ad esempio:
<Directory /home/*/public_html> ... </Directory>
4.18
Direttiva Include
Include, inserisce nella configurazione del server HTTP le direttive presenti

in un ulteriore file di configurazione, avente percorso file-path. Nella directory [INSTALL_DIR]/conf/extra di Apache sono presenti file di configurazione
aggiuntivi, che si possono includere per abilitare particolari funzionalit.
La sua sintassi Include file-path.
Ad esempio Apache 2.2 fornisce un file di configurazione esterno per abilitare
le directory personali degli utenti Include conf/extra/httpd-userdir.conf.
4.19
Controllo di accesso:elementi di base
Apache HTTP Server supporta numerose tecniche di autenticazione e autorizzazione:

Basic access authentication, usa il modulo mod_auth_basic;
Digest access authentication, usa il modulo mod_auth_digest.
La procedura per limitare laccesso a una directory ai soli utenti autorizzati
la seguente:
creare un file degli account autorizzati in una locazione non accessibile ai
client, usando il programma htpasswd fornito con linstallazione;
memorizzare nome utente e password di ogni utente autorizzato;
abilitare lautenticazione nella directory da proteggere.
Ad esempio ipotizziamo che lHTTP server sia installato in /usr/local/httpd,
che DocumentRoot sia in /usr/local/httpd/htdocs e che si voglia memorizzare il
file delle password in /usr/local/httpd/passwd/passwords. Allora la procedura
da seguire :
59
Eseguire il comando /usr/local/httpd/bin/htpasswd -c /usr/local/httpd/passwd/passwords utente1 Il programma crea (opzione -c) il file delle password e chiede di immettere e confermare la password per utente1
Eseguire il comando /usr/local/httpd/bin/htpasswd /usr/local/httpd/passwd/passwords utente2 Il programma aggiunge al file esistente nome utente e password di utente2. Ripetere il passo per tutti gli altri utenti da
autenticare
Inserire le seguenti righe in httpd.conf allinterno di una direttiva Directory
(o un file .htaccess) che si riferisce alla directory da proteggere:
<IfModule mod_auth_basic> AuthType Basic AuthName "Area riservata" AuthBasicProvider file AuthUserFile /usr/local/http/passwd/passwords Require valid-user </IfModule>
AuthName definisce un realm (contesto) di sicurezza: lutente inserir le
credenziali una volta sola e potr accedere, nella stessa sessione, a tutte
le risorse di quel realm
Questa tecnica adeguata solo nei casi in cui:
gli utenti sono pochi (il file degli account puramente testuale ricerca
sequenziale);
le esigenze di sicurezza sono modestissime (il client trasmette la password
in chiaro);
Possibilit pi avanzate permettono di:
definire gruppi di utenti (pi flessibilit);
trasmettere un hash invece della password in chiaro (pi sicuro);
usare il modulo per la crittografia con SSL/TLS (ancora pi sicuro);
memorizzare gli account in un database (pi efficiente);
usare LDAP Lightweight Directory Access Protocol per gestire gli account e le autorizzazioni (massima flessibilit).
4.20
File.htaccess
Un file .htaccess altera la configurazione del server HTTP solo per la directory
in cui si trova (e le sottodirectory). I file .htaccess hanno la stessa sintassi di
httpd.conf. Si tratta, quindi, di una tecnica alternativa ed equivalente alluso
delle direttive Directory nel file httpd.conf principale.
I vantaggi sono:
consente agli utenti di cambiare la configurazione solo per le proprie risorse, senza richiedere modifiche allamministratore del web server;
utile ai fornitori di servizi di hosting.
Gli svantaggi sono:
60
prestazioni: uno o pi accessi a file .htaccess per ogni risorsa richiesta dal
client;
sicurezza: rischi se AllowOverride concede privilegi eccessivi.
AllowOverride, indica quali direttive di Apache possono essere ridefinite
mediante file .htaccess rispetto alle impostazioni di base presenti in httpd.conf.
Si usa allinterno di una direttiva Directory e vale anche per tutte le sottodirectory.
La sua sintassi la seguente AllowOverride all|none|directive [directive]
Valori possibili sono:
none: i file .htaccess vengono ignorati da Apache (migliori prestazioni)
all: consente di ridefinire qualsiasi direttiva
un elenco di gruppi direttive di cui consentire la ridefinizione
Falso: i file .htaccess si usano solo per il controllo daccesso a una directory;
Vero: nei file .htaccess si pu usare qualsiasi direttiva;
Vero: per il controllo daccesso ci sono anche tecniche migliori.
4.21
Caching
Se presente, si pu abilitare il modulo mod_cache che permette di:

di usare Apache come proxy server HTTP con caching
se Apache usato come origin server, di attivare una cache interna (su una
memoria pi piccola ma ad accesso pi rapido) per velocizzare le risposte.
LoadModule cache_module modules/mod_cache.so <IfModule mod_cache.c> LoadModule cache_disk_module modules/mod_cache_disk.so <IfModule mod_cache_disk.c> CacheRoot c:/cacheroot CacheEnable disk
/ CacheMinFileSize 64 CacheMaxFileSize 640000 </IfModule>
CacheDisable http://www.example.com/update/ </IfModule>
dove:
c:/cacheroot la directory in cui memorizzare la cache;
CacheEnable disk / indica che la cache sar abilitata per tutte le
risorse il cui path inizia con il prefisso specificato;
CacheMinFileSize 64 indica i limiti alle dimensioni del singolo file in
cache;
CacheDisable disattiva la cache per le risorse il cui URL inizia con il
prefisso specificato.
ExpiresDefault | ExpiresByType indicano un tipo di morte di tipo
Server-specified expiration per tutte le risorse o in base al tipo MIME.
ExpiresDefault base plus num unit ... ExpiresByType type base plus num
unit ...
dove:
61
base: tempo iniziale, pu valere access o modification

unit: years|months|weeks|days|hours|minutes|seconds
Ad esempio: ExpiresDefault "access plus 1 week". ExpiresByType image/*
"modification plus 3 months ".
FileETag, indica in base a quali parametri della risorsa calcolare lETag per
la convalida.
FileETag component ...
dove le componenti adoperabili sono:
INode: numero di inode del file su filesystem;
MTime: data di ultima modifica;
Size: dimensioni;
All: tutti insieme.
4.22
Virtual host: introduzione
Dominio virtuale indica uno stesso server HTTP che serve pi domini (ad es.
www.dominio1.com e www.dominio2.com). Ogni virtual host ha una diversa
DocumentRoot. Ne esistono di due tipi:
IP-based virtual hosting: il server ha pi indirizzi IP e ciascun virtual host
associato a un diverso indirizzo;
Name-based virtual hosting (detto anche multi-homing): tutti i virtual
host sono associati ad un unico indirizzo IP (caso pi frequente).
Esempi virtual host IMMAGINE!!!!!!!
4.22.1
IP-based virtual hosting
Esistono due tecniche:

un server HTTP per ciascun hostname installare e configurare sulla stessa
macchina un esemplare del server per ciascun sito web ognuno associato
ad un indirizzo IP diverso (con la direttiva Listen) isolamento dei diversi
siti web pi sicurezza
un unico server HTTP migliori prestazioni si usa una direttiva VirtualHost
per ciascun sito web <VirtualHost IP|hostname[:port]> ... </VirtualHost>
Ad esempio
<VirtualHost 209.85.129.148> ServerName www.example.it DocumentRoot
/var/www/html/it/ ServerAdmin webmaster@example.it ErrorLog /var/log/httpd/it/error_log TransferLog /var/log/httpd/it/access_log </VirtualHost> <VirtualHost 209.85.129.105> ServerName www.example.com DocumentRoot
/var/www/html/en/ ServerAdmin webmaster@example.com ErrorLog /var/log/httpd/en/error_log TransferLog /var/log/httpd/en/access_log </VirtualHost> NB:
62
per funzionare necessario che il server DNS associ correttamente i nomi

di dominio agli indirizzi IP del server!
In ogni VirtualHost si specificano le direttive relative al singolo sito web
(almeno ServerName, DocumentRoot e le direttive per i log) [TransferLog
simile a CustomLog, ma usa lultimo formato di log specificato con
LogFormat o quello predefinito]
4.22.2
Name-based virtual hosting
Si adopera una direttiva NameVirtualHost in cui indicare lindirizzo IP del server (o * per indicare qualsiasi indirizzo) e la porta. Si adopera una direttiva
VirtualHost per ciascun dominio virtuale, con lo stesso IP di NameVirtualHost e
almeno ServerName e DocumentRoot. Il ServerAlias permette di definire forme
diverse dello stesso nome di dominio virtuale per agevolare lutente
Ad esempio: NameVirtualHost *:80 <VirtualHost *:80> ServerName www.domain.com ServerAlias domain.com *.domain.com DocumentRoot /var/www/domain </VirtualHost> <VirtualHost *:80> ServerName www.otherdomain.com
DocumentRoot /var/www/otherdomain </VirtualHost> NB: per funzionare
necessario che il server DNS associ i nomi di dominio virtuali e gli alias
allindirizzo IP del server!
4.23
Multi-processing modules
Dal punto di vista dellarchitettura software, Apache 2.4 offre diversi modelli di
multi-processing. Sono implementati attraverso moduli da scegliere a tempo di
installazione (compilazione statica). I principali modelli sono:
prefork, un singolo processo di controllo responsabile per lanciare processifigli i quali restano in ascolto per le connessioni e le servono non appena
arrivano. Apache cerca di mantenere differenti processi di scorta o inattivi
cos da provvedere prontamente a servire le richieste in arrivo. In tal modo i client non devono attendere che venga effettuato il fork di un nuovo
processo figlio per essere serviti;
worker, un singolo processo di controllo responsabile per il lancio dei
processi figlio. Ciascun processo figlio crea un numbero prefissato di
server-thread cos come specificato nella direttiva ThreadsPerChild ed un
thread-listener che resta in ascolto delle connessioni per poi passarli ai
server-thread;
event, cerca di risolvere il problema del keep-alive di HTTP. Dopo che un
client ha completato la prima richiesta esso pu mantenere la connessione
aperta ed inviare ulteriori richieste via socket. In tal modo vi un gran
risparmio di overhead nella creazione di connessioni TCP. Viene, dunque,
adoperato un thread dedicato che gestisca il listening sul socket e tutti i
socket restano in modalit keep-alive.
La scelta del modello dipender da:
tipo di applicazioni Web che il server dovr supportare;
sistema operativo (alcuni modelli sono meno efficienti su alcuni OS).
63
4.24
Prefork MPM
Modello multiprocesso non basato su thread. Le caratteristiche principali sono

le seguenti:
un unico processo master;
fork per creare un processo worker ad ogni nuova connessione;
unica possibilit in Apache 1.x;
I/O sincrono in versioni precedenti alla 2.4;
necessario se si usano altri moduli non implementati in maniera threadsafe;
indica il massimo numero di worker simultanei (connessioni concorrenti).
Il default 256. Si pu aumentare se si deve gestire un pi elevato livello
di concorrenza o diminuire se il calcolatore ha poca memoria centrale, per
evitare thrashing26 . Un esempio il seguente
<IfModule mpm_prefork_module> MaxClients 500 </IfModule> MaxClients num
4.25
Worker MPM
Si tratta di un Modello ibrido multiprocesso/multithread le cui caratteristiche

sono:
un processo master e diversi processi worker;
ogni worker ha un certo numero di thread, ognuno dei quali gestisce una
connessione;
thread pooling per evitare frequenti creazioni/distruzioni di thread;
consuma meno risorse rispetto al modello prefork.
Ad esempio <IfModule mpm_worker_module> ServerLimit 16 # max
numero di worker StartServers 2 # numero di worker iniziale MaxClients
150 # max n. di thread totali MinSpareThreads 25 # min n. di thread
liberi nel pool MaxSpareThreads 75 # max n. di thread liberi nel pool
ThreadsPerChild 25 # n. di thread per worker </IfModule>
4.26
Event MPM
E una variante del modello worker con I/O event/based. In worker, resta
in attesa un thread per ogni connessione rimasta in KeepAlive. In event, un
unico thread resta in attesa di eventi per tutte le connessioni in KeepAlive.
Non funziona con modelli di CPU pi vecchi, che non supportano operazioni
di confronto e scambio atomico a livello di ISA. Le direttive sono le stesse di
worker. Si tratta di un modello ancora sperimentale!
26 Si
tratta del trasferimento dati dalla memoria centrale allhard disk (vd. Swap).
64
4.27
XAMPP
E una piattaforma di sviluppo per il web che integra in un unico pacchetto

facile da installare i seguenti componenti:
Apache HTTP server;
MySQL (database relazionale);
PHP (linguaggio di server-side scripting);
Perl (linguaggio di server-side scripting).
E disponibile su http://www.apachefriends.org/ per Windows, Linux, Mac OS
X e Solaris, con licenza GNU GPL (free software). E indicato per ambienti
di sviluppo e test di applicazioni web. Le impostazioni di sicurezza predefinite
sono per troppo blande per luso di XAMPP in ambienti di produzione.
4.28
Riferimenti
Documentazione ufficiale Apache Software Foundation, Apache HTTP Server

Documentation, http://httpd.apache.org/docs/, 1995-2012
Nginx
Nginx (pronuncia: engine-x) un Web server open source ad elevata concorrenza, sviluppato inizialmente da Igor Sysoev, poi da Nginx Inc. La prima versione
pubblica risale al 2004. Pu svolgere il ruolo di:
Web server;
Reverse proxy per HTTP, HTTPS, SMTP, POP3, IMAP.
Risulta configurabile ed estensibile attraverso moduli ed disponibile per
sistemi operativi UNIX-like (Linux, Mac OS X, Solaris, etc.) e Windows.
5.1
Nginx vs. Apache
Apache HTTPd , dal punto di vista del multi-processing model, configurabile

attraverso moduli MPM. Prima della versione 2.4 usava primitive di comunicazione sincrone (bloccanti) e ci poteva creare problemi di scalabilit, anche
usando thread pool27 .
Quando il carico cresce massicciamente, con un numero di connessioni concorrenti nellordine delle decine di migliaia, lunica soluzione avere un reverse proxy con load balancing verso un numero di macchine elevato, con un
quantitativo totale di RAM sufficiente a soddisfare le richieste.
Nginx, come altri Web server di recente generazione (Lighttpd, etc.), adotta
unarchitettura diversa, con primitive di comunicazione asincrone (non bloccanti) e event-based: in questo modo, quando il numero di connessioni concorrenti
cresce, il consumo di memoria centrale aumenta molto lentamente.
27 Thread pool indica un gestore software di thread utilizzato per ottimizzare e semplificare
il loro utilizzo allinterno di un programma.
65
Nginx ha un master process e un certo numero di worker process. Poich

ciascun worker in grado di gestire numerose connessioni concorrenti, non conviene configurare un numero di worker superiore al numero di core di CPU
disponibili.
5.1.1
Installazione in ambiente Windows
Per i sistemi Windows distribuito un pacchetto dinstallazione precompilato.

5.1.2
Installazione in ambiente UNIX-like
Linstallazione in ambiente Linux si effettua da pacchetti precompilati (RPM,

DEB) nel packet manager della propria distribuzione oppure per compilazione di
sorgenti scaricati da http://wiki.nginx.org/Install#Source_Releases mediante i
seguenti passi:
estrazione dellarchivio;
./configure;
make;
make install.
Il percorso dinstallazione predefinito /usr/local/nginx, ma si pu cambiare
con le opportune opzioni di compilazione. Il percorso predefinito del file di
configurazione [INSTALL_DIR]/conf/nginx.conf.
5.1.3
Avvio, arresto, riavvio (ambiente UNIX-like)
Leseguibile (daemon) si avvia col comando [INSTALL_DIR]/sbin/nginx. Tale

comando richiede i privilegi di root per essere eseguito e possiede alcuni parametri opzionali. Di seguito le procedure per avviare, arrestare o riavviare il
daemon:
Arresto , [INSTALL_DIR]/sbin/nginx -s stop;
Arresto graceful, [INSTALL_DIR]/sbin/nginx -s quit;
Ricarica al volo il file di configurazione (senza fermare loperativit del
server), [INSTALL_DIR]/sbin/nginx -s reload.
5.1.4
Test
Una volta avviato, accedendo con un browser a http://localhost si dovrebbe

avere una risposta positiva.
IMMAGINE!!!!
5.1.5
File di configurazione nginx.conf
Come per Apache, anche il file di configurazione di Nginx un file testuale

costituito da un insieme di direttive. La principale differenza che ci sono
diversi contesti a cui un blocco di direttive pu essere applicato. I principali
sono:
66
HTTP, blocco valido per lintera istanza del Web server;

server, blocco valido solo per un determinato virtual host;
location, blocco valido solo per una determinato insieme di risorse (individuato da unespressione regolare) allinterno di un virtual host; si possono
nidificare pi contesti location.
Lapplicazione procede gerarchicamente fra HTTP, server e location. nginx
seleziona sempre il match pi specifico tra quelli trovati.
5.1.6
Esempio di virtual hosting
IMMAGINE!!!!!!!!!!
5.1.7
Ngynx come proxy server
IMMAGINE!!!!!!
5.1.8
Considerazioni prestazionali
Le ultime versioni di Apache (2.4.x) hanno prestazioni generalmente paragonabili a Nginx anche se non possono supportare livelli estremi di concorrenza.
Nginx , rispetto ad Apache:
veloce nel servire risorse statiche;
lento nel servire risorse dinamiche.
Allora una tipica configurazione avr Nginx come server per le risorse statiche mentre un proxy verso Apache per le risorse dinamiche.
Documentazione ufficiale su http://nginx.org/en/docs/ M. Fjordvald, Instant Nginx Starter, ebook C. Nedelcu, Nginx HTTP Server, ebook
Sistemi informativi distribuiti: layer, tier, metodologie di progetto
Un sistema informativo un sistema hardware/software che consente lesecuzione di operazioni per laccesso e la modifica di informazioni. Un sistema si
dice distribuito se i diversi componenti, che concorrono allo svolgimento delle
funzionalit del sistema, sono eseguiti su calcolatori indipendenti (interconnessi
in rete). Lo scopo di un sistema informativo , in generale, automatizzare in
tutto o in parte i processi svolti da unorganizzazione (azienda, ente, comunit
di persone, ecc.) dislocata su un territorio. Spesso il sistema informativo solo
una parte di un sistema pi complesso nel mondo reale, che comprende persone
ed oggetti.
Per progettare un sistema informativo distribuito necessario definire:
protocolli di comunicazione tra i vari componenti;
formati per linterscambio dei dati necessari a richiedere operazioni e a
restituire le risposte.
67
6.1
Architettura di un sistema informativo distribuito
Larchitettura di un sistema informativo distribuito prevede le seguenti componenti:

Presentation layer, rappresenta uninterfaccia verso utenti e sistemi
esterni (client) per consentire laccesso ai servizi forniti dal sistema. Ad
esempio la GUI (Graphical User Interface);
Application Logic Layer (a.k.a. business logic, business processes, business rules), implementa le operazioni svolte dal sistema;
Resource Management Layer, interfaccia del sistema verso le sorgenti
di dati su cui deve operare.
IMMAGINE ARCHITETTURA SIST. DISTRIBUITO!!!!
Il client e il presentation layer possono essere:
separati, come nel caso delle Web application, in cui il livello di presentazione implementato in HTML, CSS e linguaggi di scripting, mentre il
client il Web browser;
integrati, cio un unico oggetto permette allutente di accedere direttamente ai servizi del livello di logica applicativa. Ad esempio una banca
pu fornire loperativit ai clienti tramite Web application e/o tramite
app per smartphone.
Non detto che il client agisca per un utente umano; pu trattarsi di un
altro sistema.
Similmente, tra le sorgenti dati possono esserci (R)DBMS28 , ma anche
filesystem, altri tipi di basi di dati o sistemi esterni a cui il nostro sistema
deve richiedere dati per poter svolgere i suoi compiti. Larchitettura vista pu
dunque essere ripetuta ricorsivamente, con sistemi che fungono da componenti
per sistemi pi grandi.
6.2
Metodologie di progetto
Esistono due principali metodologie di progetto per sistemi informativi distribuiti:

Top-down;
Bottom-up.
6.2.1
Top - down
La funzionalit del sistema divisa in componenti (moduli), che non possono

operare separatamente ma sono interdipendenti (tightly coupled, fortemente accoppiati). Tipicamente lhardware omogeneo e il sistema progettato
come distribuito sin dal principio. La progettazione direttamente guidata dai
requisiti (funzionali e non funzionali) del sistema.
28 Il
termine Relational database management system (RDBMS) (sistema per la

gestione di basi di dati relazionali) indica un database management system basato sul modello
relazionale, ed stato introdotto da Edgar F. Codd.
68
IMMAGINE ARCHITETTURA TOP DOWN!!

Riassumendo, nellarchitettura top - down un sistema distribuito funziona
attraverso le seguenti fasi:
il client definisce i canali di accesso e le piattaforme client;
il presentation layer definisce i formati di presentazione e i protocolli
per i client;
l application logic layer definisce le funzionalit necessarie a fornire i
contenuti ed i formati richiesti dal presentation layer;
resource management layer definisce le sorgenti di dati e lorganizzazione dei dati necessari per implementare la logica applicativa.
6.2.2
Bottom - up
In un progetto bottom-up, si parte da componenti di base che esistono gi

(legacy). Essi sono sistemi stand-alone che devono essere integrati in nuovi
sistemi. I componenti non cessano necessariamente di operare anche come componenti stand-alone (perch le vecchie applicazioni devono continuare a funzionare contemporaneamente a quelle nuove). Questo approccio molto applicato,
perch spesso esistono gi dei componenti che non possono essere facilmente
sostituiti. I componenti del sistema risultano, in genere, debolmente accoppiati
(loosely coupled).
IMMAGINE ARCHITETTURA BOTTOM UP
Riassumendo, nellarchitettura bottom - up un sistema distribuito funziona
attraverso le seguenti fasi:
il client definisce i canali di accesso e le piattaforme client;
il resource management layer esamina le risorse esistenti e le funzionalit che esse offrono;
l application logic layer definisce wrapper per le risorse esistenti e
integra le loro funzionalit in una interfaccia coerente;
il presentation layer adatta loutput del livello di logica applicativa in
maniera tale da essere adoperato con i canali daccesso e i protocolli definiti
per i client.
6.2.3
Confronto tra Top - down e Bottom - up
La progettazione top-down pi semplice perch condizionata da meno vincoli.

Il progetto risulta cos pi facilmente conforme ai requisiti di sistema funzionali
(operazioni da svolgere) e non funzionali (prestazioni, disponibilit, sicurezza,
etc.). Lapproccio top-down, tuttavia, applicabile solo se il sistema deve essere
realizzato da zero mentre, attualmente, nella maggioranza dei casi si parte da
sistemi legacy: la progettazione devessere, gioco forza, di tipo bottom-up.
Molto del lavoro in tali casi riguarda il middleware, livello intermedio necessario per integrare i componenti legacy risolvendo le criticit nelle modalit
seguenti:
fornendo interfacce comuni;
69
affrontando leterogeneit hardware e software dei componenti;

affrontando le problematiche (non previste nei sistemi legacy) legate alla
natura distribuita del nuovo sistema.
6.3
Componenti del sistema, layer e connessioni
Figura 31: Esempio di architettura di un sistema distribuito

Con riferimento alla Fig. 31:
ogni box rappresenta un componente del sistema;
ogni freccia rappresenta una connessione tra due componenti;
una maggiore modularit permette maggior distribuzione e parallelismo,
agevola lincapsulamento, la progettazione basata su componenti e il riuso;
di contro pi componenti implicano pi connessioni: occorre mantenere
pi sessioni, richiesta una maggior coordinazione. Il sistema diventa pi
complesso da monitorare e gestire. Pi sono i livelli, maggiore il numero
di passi intermedi da compiere per completare unoperazione con notevole
impatto sulle prestazioni del sistema;
i progettisti devono bilanciare la flessibilit della progettazione modulare
con le richieste prestazionali delle applicazioni.
Non c problema di progettazione che non si possa risolvere aggiungendo un
livello di indirezione. Non c problema di prestazioni che non si possa risolvere
eliminando un livello di indirezione.
70
6.3.1
Layer e tier
La suddivisione dellarchitettura di un sistema informativo nei 3 layer (livelli)

descritti vale dal punto di vista logico. Dal punto di vista fisico, nelle fasi di
progettazione, sviluppo e deployment essi vengono mappati in uno o pi tier
(strati) di componenti indipendenti. I modelli architetturali principali sono:
1-tier;
2-tier;
3-tier;
N-tier.
Architettura 1-tier I livelli di presentazione, logica applicativa e gestione
risorse sono fusi in un sistema monolitico. Modello adottato dai sistemi pi
vecchi, basati su mainframe centralizzati e dumb terminal (semplici terminali
dotati di schermo e tastiera per lI/O e connessione al mainframe, senza capacit di elaborazione proprie) come client. Seguendo i principi e le pratiche
dellIngegneria del Software, la progettazione di nuovi sistemi tende ad evitare
il modello 1-tier; oggi, perci, si trova essenzialmente in sistemi legacy.
IMMAGINE 1 TIER!!!
I limiti pi evidenti sono:
unica interfaccia verso il sistema sono i dumb client; non esiste uninterfaccia di servizi o API che altri sistemi possono usare per usufruire delle
funzionalit;
volendo interfacciare il sistema con un altro o integrarlo in uno pi grande,
lunico modo sviluppare un wrapper29 , componente che interagisca col
sistema fornendo linput e ricevendo loutput come se si trattasse di un
client; si tratta di una soluzione poco elegante ed efficiente perch bisogna
formattare linput nel modo che il sistema si aspetta (spesso non ben
documentato) ed effettuare screen scraping30 delloutput;
a causa della concentrazione di tante funzionalit in un unico grande componente (con codice spesso non ben documentato), la manutenzione e
levoluzione del sistema sono molto costose.
I vantaggi pi evidenti sono:
prestazioni superiori;
nessun costo di sviluppo e manutenzione di interfacce;
manutenzione dei client pressoch nulla.
29 In informatica, e in particolare in programmazione, un wrapper (dal verbo inglese to
wrap, "avvolgere") un modulo software che ne "riveste" un altro, ovvero che funziona da
tramite fra i propri clienti (che usano linterfaccia del wrapper) e il modulo rivestito (che svolge
effettivamente i servizi richiesti, su delega delloggetto wrapper). Il principio si pu applicare
a sottoprogrammi come funzioni e metodi o a interi tipi, classi o oggetti.
30 Con il termine screen scraping ci si riferisce allatto mediante il quale si recupera loutput
da una sorgente col fine di riadoperarlo per scopi altri. Un possibile esempio lintegrazione
dei risultati di una query fatta ad un servizio meteorologico nel proprio sito web.
71
Architettura 2-tier Rappresenta il tipico paradigma client-server. In base

alla complessit dei client , i sistemi 2-tier si possono suddividere in:
Thin client;
Fat (thick) client.
IMMAGINE 2 TIER!!!!
Implementare il layer di presentazione sui client permette di
liberare risorse sul server (consentendo comunque ottimizzazioni nei layer
pi bassi, come il modello 1-tier);
adattare la presentazione in base a diverse tipologie di calcolatori (portabilit) o di utenti (personalizzazione).
E necessario progettare (e documentare!) uninterfaccia stabile. Fissati
server e interfaccia, si possono sviluppare pi client diversi e indipendenti.
Storicamente, si sono avute interfacce di 2 tipi:
API basate su RPC (Remote Procedure Call);
Protocolli + formati di scambio dati (miglior disaccoppiamento; permette
a un client di interagire con pi server senza complicarne la logica interna).
Architettura 3-tier Se il client deve accedere a due o pi server con API e
logiche applicative diverse, esso deve farsi carico dellintegrazione (client sempre
pi fat). Per ovviare a ci, nel modello 3-tier, i 3 livelli sono pienamente separati.
IMMAGINE 3 TIER!!!!!!
Lintegrazione fornita a livello di logica applicativa da uno strato di
middleware. Il middleware costituisce un livello di indirezione tra i client e il
resto del sistema.
Figura 32: Il Middleware: livello di indirezione

In tal modo:
si semplifica il progetto dei client riducendo il numero di interfacce;
72
fornisce accesso ai componenti sottostanti in modo trasparente;

si occupa di individuare le risorse, accedervi e raccogliere i risultati;
funge da piattaforma per lintegrazione tra pi sistemi.
Il middleware stesso si pu vedere come un sistema generalmente progettato
con architettura 2-tier. Esso per non costituisce un sistema completo, ma
solo una piattaforma che offre funzionalit che riducono i costi di sviluppo e
deployment dei propri sistemi.
Figura 33: Il Middleware: architettura 2-tier

Ladozione di uno strato di middleware permette di:
centralizzare il controllo (semplifica la progettazione del sistema);
modularizzare e distribuire su un cluster di nodi sia i componenti di logica
applicativa sia quelli di gestione delle risorse consentendo una maggiore
scalabilit;
conferire propriet al sistema, tecnicamente difficili (costose) da implementare ma di utilit generale (riusabili in sistemi diversi), come:
tolleranza ai guasti (fault tolerance);
bilanciamento del carico (load balancing);
73
logging;
sicurezza e policy configurabili per laccesso alle risorse;
replica (replication) dei dati;
persistenza.
Di contro, luso di middleware comporta
maggior overhead di comunicazione tra i componenti del sistema;
necessit di uninterfaccia stabile non solo tra presentazione e logica applicativa, ma anche tra logica applicativa e gestione delle risorse.
Architettura N-tier Le architetture N-tier (o multi-tier) nascono dalla connessione di pi sistemi 3-tier o dallinclusione di un livello di accesso al sistema
attraverso Web server. Il livello Web, in principio esterno al sistema, oggi
sempre pi spesso incorporato nel layer di presentazione residente sul server:
come parte del middleware, in unarchitettura 3-tier (Web application
server);
come parte del server, in unarchitettura 2-tier.
Comunicazione tra moduli La comunicazione tra moduli pu avvenire mediante interazioni:
bloccanti, pi semplici da progettare e implementare ma caratterizzate
da minori performance;
non bloccanti, consentono
maggiori performance;
maggiore disaccoppiamento;
richiede pi risorse ed pi difficile da implementare.
Middleware
Il Middleware facilita:
interazione;
integrazione;
tra piattaforme di calcolo distribuite ed eterogenee.
Il middleware, dal punto di vista del progettista e dello sviluppatore, unastrazione della programmazione (come una qualsiasi libreria). Offre funzionalit
che altrimenti andrebbero programmate da zero e consente di concentrare lo sviluppo sulle problematiche di pi alto livello. Si tratta, quindi, di una suite di
componenti software da installare, configurare, monitorare, aggiornare.
Esistono differenti tipi di middleware:
RPC (Remote Procedure Call);
74
TP (Transaction Processing) monitors;

Object brokers;
Object monitors;
MOM (Message-Oriented Middleware);
Message brokers;
Workflow management systems;
Application servers.
7.1
RPC - Remote Procedure Call
Nati negli anni 1980, quando nellinformatica era prevalente il modello di programmazione strutturata procedurale, ha contribuito a rendere popolari
le applicazioni distribuite di tipo client-server (2-tier).
Eseguire una chiamata a procedura da un client verso un server remoto
simile ad una chiamata a procedura interna ad un programma.
IMMAGINE PILA!!!
Larchitettura RPC adoperata sfrutta il concetto degli stub (spezzoni, adattatori ). Sia sul client che sul server sono presenti degli adattatori delle funzioni
da invocare/invocate: questi veri e propri pezzi di codice permettono di rendere
completamente trasparente al programmatore alcune azioni meccaniche come
lidentificazione della macchina server, lattuazione della procedura di send della richiesta al server, la gestione dei parametri della chiamata a funzione. Il
programmatore non dovr pi gestire queste azioni manualmente. Si parla in
tal caso di RPC trasparente. Se il programmatore richiede pi controllo
adoperabile un RPC non trasparente.
In sintesi, una chiamata a procedura remota avviene seguendo questi passi:
la procedura client richiama il client stub nel modo normale;
il client stub costruisce un messaggio e richiama il sistema operativo locale;
il SO del client invia il messaggio al so remoto;
il SO remoto passa il messaggio al server stub;
il server stub spacchetta i parametri e richiama il server;
il server esegue il lavoro e restituisce il risultato allo stub;
il server stub lo impacchetta in un messaggio e richiama il suo SO;
il SO del server invia il messaggio al SO del client;
il SO del client passa il messaggio al client stub;
lo stub spacchetta il risultato e lo restituisce al client.
Come possibile che un client possa effettuare una chiamata di funzione con
puntatori? Le due macchine non condividono lo stesso spazio di indirizzi! Per
risolvere questo problema stato introdotto il meccanismo di copia/ripristino.
Esso consiste nel:
75
copiare le celle di memoria puntate dal puntatore nel messaggio ed inviarle

al server (es. copio un array nel messaggio e lo invio al server);
lo stub server pu quindi effettuare una chiamata locale al proprio sistema operativo fornendo come puntatore lindirizzo dellarray contenuto nel
messaggio ricevuto dal client. In tal modo sebbene lo spazio degli indirizzi
sia differente fra le due macchine come se effettivamente il server facesse
riferimento allo stesso indirizzo del client per gestire larray;
ciascun cambiamento effettuato durante lelaborazione del server sullarray
ricevuto, generer cambiamenti anche sullarray originario del client;
nel momento in cui lelaborazione del server termina, larray, modificato dal
server, potr essere trasmesso al client stub che lo copier sulla macchina
client.
Una ottimizzazione di tale paradigma permette una migliore efficienza:
nel caso in cui larray sia un parametro di input necessario al solo server (e
quindi se esso non deve essere restituito al client) la copia dellarray pu
non essere ricopiata sul client stub;
nel caso in cui larray sia un parametro elaborato dal solo server e poi
restituito al client non c necessit che il client crei un array da passare al
server.
Ma come fare a far comunicare macchine che presentino organizzazione dei
dati e/o protocolli di rete differenti fra loro? possibile inserire la codifica dei
dati trasmessi direttamente nel messaggio inviato cos da risolvere ogni problema
di compatibilit.
In alternativa necessario concordare un unico formato fra le macchine
costituenti il sistema distribuito.
Infine possibile prevedere lesistenza di un componente intermedio che permetta conversioni di tipo (es. little endian vs big endian). Per quanto riguarda il
protocollo di rete strettamente necessario che esso sia condiviso fra le macchine
costituenti il sistema distribuito.
Fortunatamente gli stub di uno stesso protocollo ma per procedure differenti,
differiscono esclusivamente per linterfaccia, dove per interfaccia si intende la serie di servizi che un server rende disponibili ad un client. Per semplificare la vita
le interfacce sono definite tramite IDL ( Interface Definition Language):
permette la descrizione delle operazioni remote, la specifica del servizio
(detta firma) e la generazione degli stub (non posso essere piu esaustivo
perch sul libro non c molto a riguardo).
Unulteriore particolarit delle RPC la possibilit che esse siano sincrone
o asincrone. Se la modalit di chiamata sincrona il client bloccato in
attesa della ricezione dellelaborazione del server: nel caso in cui il risultato
dellelaborazione non debba essere restituito al client tale blocco evitabile.
Al contrario una modalit di chiamata asincrona permette al client di continuare ad operare su altri task dopo aver effettuato la chiamata alla procedura
remota: nel momento in cui il server riceve il messaggio da parte del client invia
a questultimo un messaggio di avvenuta accettazione (acknowledgement)
76
in modo tale da permettere al client di continuare le proprie elaborazioni indipendentemente dal risultato della elaborazione del server. Tale modalit tipica
di quelle elaborazioni in cui il client non necessita del ritorno del risultato della
elaborazione server.
Nel caso in cui il client necessiti di tale valore di ritorno, possibile impiegare
una modalit di RPC differita o a 2 fasi. Nella prima fase il client attua una
RPC asincrona verso il server, nella seconda fase il server ad attuare una
RPC asincrona verso il client per comunicare il valore di ritorno della propria
elaorazione.
7.1.1
Binding
Come fanno client e server ad instaurare la connessione? Il meccanismo che

consente al client di connettersi al giusto server sul quale invocare la procedura
remota prende il nome di binding. Esistono due differenti tipologie di binding:
binding statico, lindirizzo del server gi impostato nel client. di
facile implementazione ma vi assenza di trasparenza;
binding dinamico, stabilisce lindirizzo del server in base alla necessit
attuale. Vi un maggiore costo implementativo e computazionele a fronte
di maggiore trasparenza e flessibilit.
Binding dinamico Esso consta di due fasi:
Naming, fase precedente allesecuzione: il client specifica a chi deve connettersi indicando un nome server univoco, identificativo del servizio. Si
associano nomi univoci alle operazioni o alle interfacce astratte e con esse
si effettua il binding (es. FunzioneSomma);
Addressing, fase dinamica a runtime: cercati i server che posseggono il
servizio richiesto nella fase di Naming, il client deve effettivamente connettersi al server corretto. Per compiere questazione sono presenti due
differenti vie:
Addressing esplicito: il client invia messaggi broadcast o multicast
(cio messaggi multipli) e si connette al server che risponde per primo;
Addressing implicito: il client interroga un nameserver, contenente opportune tabelle di binding nelle quali sono memorizzate le
caratteristiche dei server, e si connette con il server indicato dal
nameserver.
Da ultimo opportuno specificare che il binding dinamico spesso viene effettuato solo alla prima chiamata: ottenuto lindirizzo del server a cui connettersi
solitamente le successive RPC avvengono con binding statico. Tutto ci per
via della frequenza elevata con cui si effettuano le RPC che comporterebbe un
notevole costo computazionale nel caso ad ogni chiamata si effettuasse binding
dinamico.
77
SOA e Web Service
Web Service: tecnologie
10
Web Service: composizione, BPEL, ESB
11
Linguaggi di schema e DTD
12
REST, Web 2.0
13
Cloud Computing
14
Information retrieval con Apache Lucene
15
WebSocket (RFC 6455)
16
Online marketplaces
17
Sponsored Search
18
Web of Things
19
Hadoop
78
Riferimenti bibliografici
[1] M.W. Godfrey A. Grosskurth. Architecture and evolution of the modern
web browser,(Univ. of Waterloo, Canada). url: http://grosskurth.ca/
papers/browser-archevol-20060619.pdf.
[2] Andrea DAlessandro. Una Storia dellIpertesto. url: http://areeweb.
polito . it / didattica / polymath / ICT / Htmls / Argomenti / Appunti /
StoriaIpertesto/StoriaIpertesto.htm.
[3] W3C Network Working Group. Hypertext Transfer Protocol HTTP/1.1.
url: http://tools.ietf.org/html/rfc2616.
[7] UniSa. RFC 822 e MIME. url: http://www.di.unisa.it/~ads/corsosecurity/www/CORSO-0203/SMIME/doc/RFC%20822%20e%20MIME.htm.
[8] W3C. W3C Process. url: http://www.w3.org/2014/Process-20140801/.
[9] Wikipedia. SGML. url: http://it.wikipedia.org/wiki/Standard_
Generalized_Markup_Language.
[10] Wikipedia. W3C. url: http://it.wikipedia.org/wiki/World_Wide_
Web_Consortium.
[11] Wikipdia. bnf. url: http://it.wikipedia.org/wiki/Backus- Naur_
Form.
[12] Wikipdia. cURL. url: http://en.wikipedia.org/wiki/CURL.
79

Linguaggi e Tecnologie Per Il Web

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Linguaggi e Tecnologie Per Il Web

Caricato da

Copyright:

Formati disponibili

Linguaggi e tecnologie per il Web

Attilio Nicola Nocera

2 Architettura del WWW browser, Unicode, URL

4.22.1 IP-based virtual hosting . .

6 Sistemi informativi distribuiti: layer, tier, metodologie di progetto

9 Web Service: tecnologie

10 Web Service: composizione, BPEL, ESB

11 Linguaggi di schema e DTD

12 REST, Web 2.0

14 Information retrieval con Apache Lucene

15 WebSocket (RFC 6455)

Cosa mi appresto ad imparare?

Principali tecnologie del Web e sistemi informativi orientati al Web;

Cosa sar in grado di realizzare dopo aver studiato?

Sar in grado di utilizzare le principali tecnologie Web;

Architettura del WWW browser, Unicode, URL

Paul Otlet1 nel 1910, in occasione dellEsposizione mondiale di Bruxelles, assieme

Figura 1: Paul Otlet

combinate per fornire innovative funzioni di ricerca e analisi dellinformazione.

Figura 2: Vannevar Bush

Figura 3: Memex, cos come ideato da Bush

La lettura di As We May Think fulmin diversi ricercatori che da quel momento

Figura 4: Theodore Holme Nelson

Tim Berners Lee e le origini del World Wide Web

Figura 5: Tim Berners Lee

Figura 6: Architettura Client - Server

Il capo di Berners-Lee, Mike Sendall, approv il progetto per lo sviluppo di

Architettura del WWW

Le tre tecnologie fondamentali alla base del WWW sono:

aziende informatiche di primaria importanza, come Adobe, Apple, Cisco

risolve le problematiche relative alle architetture Web;

registrare la decisione del gruppo di procedere con lavanzamento;

pubblicazione, non strettamente necessaria, di un lavoro di revisione del

Tali requisiti sono:

mostrare una esperienza implementativa adeguata;

Una Recommendation deve:

identificare dove siano presenti gli errata;

Figura 7: Processo di stesura di un Recommendation

Rendering Engine, fornisce una rappresentazione visuale per un URI

Figura 8: Motori JavaScript con JIT Compiler

XML Parser, effettua il parsing dei documenti XML in un albero DOM.

Figura 9: Architettura di un Web browser

Figura 10: Differenti tipi di rendering engine

Figura 11: Architettura del browser Mozilla Firefox

Figura 12: Architettura di un proxy - browser

Tcs , rappresenta il tempo di trasferimento dei dati;

Figura 13: Pila TCP/IP

HTTP (HyperText Transfer Protocol ) un protocollo di livello applicativo

Principio di funzionamento di HTTP

Figura 14: Schema di funzionamento del modello client - server

HTTP esistito in tre versioni:

Analizziamo lo scenario di applicazione di una connessione HTTP evidenziandone gli attori:

Struttura dei messaggi HTTP

I messaggi HTTP seguono la Backus - Naur Form.

Backus - Naur Form

Le seguenti regole sono usate nella descrizione dei messaggi HTTP:

OCTET = <qualsiasi sequenza di 8 bit>

CHAR = < qualsiasi carattere US-ASCII (octet 0 - 127)>

HTTP: tipologia messaggi

I messaggi HTTP (versione 1.1) consistono in richieste da un client ad un server

ogni coppia oggetto/formato costituisce un tipo MIME (MIME type o

HTTP: Message Length

Il transfer - length di un messaggio dato dalla lunghezza del message - body