Linguaggi e tecnologie per il Web

7/25/2019 Linguaggi e tecnologie per il Web

1/79

Linguaggi e tecnologie per il Web

Attilio Nicola Nocera

11 aprile 2015

Indice

1 Introduzione 41.1 Cosa mi appresto ad imparare? . . . . . . . . . . . . . . . . . . . 41.2 Cosa sar in grado di realizzare dopo aver studiato? . . . . . . . 4

2 Architettura del WWW browser, Unicode, URL 42.1 Ipertesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Paul Otlet. . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Vannevar Bush . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Ted Nelson . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Tim Berners Lee e le origini del World Wide Web . . . . 102.1.5 Architettura del WWW . . . . . . . . . . . . . . . . . . . 122.1.6 WorldWideWeb Consortium. . . . . . . . . . . . . . . . . 12

Attori del W3C . . . . . . . . . . . . . . . . . . . . . . . . 13

Iter delle specifiche W3C . . . . . . . . . . . . . . . . . . 142.1.7 Web Browser . . . . . . . . . . . . . . . . . . . . . . . . . 16

Architettura di un Web browser . . . . . . . . . . . . . . 16Architettura di Mozilla Firefox . . . . . . . . . . . . . . . 19Proxy based browser . . . . . . . . . . . . . . . . . . . . . 20Compatibilit dei browser . . . . . . . . . . . . . . . . . . 21

3 HTTP 223.1 Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Principio di funzionamento di HTTP . . . . . . . . . . . . . . . . 223.3 Versioni di HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Entit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Struttura dei messaggi HTTP . . . . . . . . . . . . . . . . . . . . 24

3.5.1 Backus - Naur Form . . . . . . . . . . . . . . . . . . . . . 24BNF rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Esempio di BNF . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.2 HTTP: tipologia messaggi . . . . . . . . . . . . . . . . . . 263.5.3 HTTP: Header . . . . . . . . . . . . . . . . . . . . . . . . 263.5.4 HTTP: MIME . . . . . . . . . . . . . . . . . . . . . . . . 263.5.5 HTTP: Body . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.6 HTTP: Message Length . . . . . . . . . . . . . . . . . . . 283.5.7 HTTP: Header generici . . . . . . . . . . . . . . . . . . . 293.5.8 HTTP: Header field dellentit . . . . . . . . . . . . . . . 293.5.9 HTTP: Request message. . . . . . . . . . . . . . . . . . . 30

1


2/79

Request - Line . . . . . . . . . . . . . . . . . . . . . . . . 30

Metodi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5.10 HTTP: Response message . . . . . . . . . . . . . . . . . . 34

Status code . . . . . . . . . . . . . . . . . . . . . . . . . . 34Reason phrase . . . . . . . . . . . . . . . . . . . . . . . . 35Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5.11 HTTP: Authentication. . . . . . . . . . . . . . . . . . . . 36Basic access authentication . . . . . . . . . . . . . . . . . 36Digest access authentication. . . . . . . . . . . . . . . . . 37

3.6 Connessione HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . 373.6.1 HTTP 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.6.2 HTTP 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.7 Gestione delle sessioni . . . . . . . . . . . . . . . . . . . . . . . . 393.7.1 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Architettura di un cookie . . . . . . . . . . . . . . . . . . 39Alternative ai cookie . . . . . . . . . . . . . . . . . . . . . 40Third - Party Cookies . . . . . . . . . . . . . . . . . . . . 41

3.8 Proxy server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.8.1 Reverse proxy. . . . . . . . . . . . . . . . . . . . . . . . . 42

3.9 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.9.1 Convalida della risorsa in cache . . . . . . . . . . . . . . . 43

Convalidatori (validators) . . . . . . . . . . . . . . . . . . 433.10 Modelli di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . 44

TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Apache HTTP Server 454.1 Installazione nei S.O. Windows . . . . . . . . . . . . . . . . . . . 464.2 Installazione nei S.O. UNIX-like. . . . . . . . . . . . . . . . . . . 464.3 Avvio del server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Avvio come servizio di sistema . . . . . . . . . . . . . . . . . . . 504.5 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6 Direttive di base . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7 Moduli. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 Server-side include . . . . . . . . . . . . . . . . . . . . . . . . . . 534.9 Direttiva IfModule . . . . . . . . . . . . . . . . . . . . . . . . . . 534.10 Log degli errori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.11 Log degli accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.12 Direttive per le directory. . . . . . . . . . . . . . . . . . . . . . . 554.13 Direttiva per i file . . . . . . . . . . . . . . . . . . . . . . . . . . 564.14 Ridirezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.15 Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.16 Messaggi derrore personalizzati. . . . . . . . . . . . . . . . . . . 584.17 Directory personali degli utenti . . . . . . . . . . . . . . . . . . . 584.18 Direttiva Include . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.19 Controllo di accesso:elementi di base . . . . . . . . . . . . . . . . 594.20 File.htaccess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.21 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.22 Virtual host: introduzione . . . . . . . . . . . . . . . . . . . . . . 62

2


3/79

4.22.1 IP-based virtual hosting . . . . . . . . . . . . . . . . . . . 62

4.22.2 Name-based virtual hosting . . . . . . . . . . . . . . . . . 634.23 Multi-processing modules . . . . . . . . . . . . . . . . . . . . . . 634.24 Prefork MPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.25 Worker MPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.26 Event MPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.27 XAMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.28 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Nginx 655.1 Nginx vs. Apache. . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.1 Installazione in ambiente Windows . . . . . . . . . . . . . 665.1.2 Installazione in ambiente UNIX-like . . . . . . . . . . . . 665.1.3 Avvio, arresto, riavvio (ambiente UNIX-like) . . . . . . . 66

5.1.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.1.5 File di configurazione nginx.conf . . . . . . . . . . . . . . 665.1.6 Esempio di virtual hosting. . . . . . . . . . . . . . . . . . 675.1.7 Ngynx come proxy server . . . . . . . . . . . . . . . . . . 675.1.8 Considerazioni prestazionali . . . . . . . . . . . . . . . . . 67

6 Sistemi informativi distribuiti: layer, tier, metodologie di pro-getto 676.1 Architettura di un sistema informativo distribuito . . . . . . . . 686.2 Metodologie di progetto . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.1 Top - down . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2.2 Bottom - up. . . . . . . . . . . . . . . . . . . . . . . . . . 696.2.3 Confronto tra Top - down e Bottom - up. . . . . . . . . . 69

6.3 Componenti del sistema, layer e connessioni . . . . . . . . . . . . 706.3.1 Layer e tier . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Architettura 1-tier . . . . . . . . . . . . . . . . . . . . . . 71Architettura 2-tier . . . . . . . . . . . . . . . . . . . . . . 72Architettura 3-tier . . . . . . . . . . . . . . . . . . . . . . 72Architettura N-tier . . . . . . . . . . . . . . . . . . . . . . 74Comunicazione tra moduli. . . . . . . . . . . . . . . . . . 74

7 Middleware 747.1 RPC - Remote Procedure Call . . . . . . . . . . . . . . . . . . . 75

7.1.1 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Binding 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

3


4/79

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

1 Introduzione1.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 quelleemergenti;

aspetti teorici e pratici della ricerca di informazioni non strutturate sulWeb 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 teorichee 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 Architettura del WWW browser, Unicode, URL

2.1 Ipertesto

Lipertesto una collezione di documenti connessi reciprocamente da collega-menti ipertestuali (hyperlink). Pi specificatamente un ipertesto consiste es-senzialmente in un testo non lineare e non sequenziale, formato da docu-menti a loro volta composti da una collezione di nodi (frammenti di testo o altrimedia) connessi da collegamenti.

Lorigine del termine scissa dal concepimento del WorldWideWeb e, se-manticamente, ha acquisito lattuale significato mediante differenti contributiforniti in epoche diverse.

4


5/79

2.1.1 Paul Otlet

Paul Otlet1 nel 1910, in occasione dellEsposizione mondiale di Bruxelles, assiemead Henri La Fontaine cre uninstallazione chiamata Mundaneum, che avrebbedovuto rappresentare una cittadella dellintelletto, il centro pulsante di una cittutopica che ospitasse la societ delle nazioni mondiali. Nel 1919, Otlet convinseil Re Alberto del Belgio a fornire una nuova sede al Mundaneum, in 150 stanzedel Palais du Cinquantenaire, allinterno della quale riun il suo vasto edificiodocumentario, con pi di 12 milioni di schede e documenti.

Figura 1: Paul Otlet

Otlet era preoccupato dal problema della fruibilit del database stesso. Ver-so la fine degli anni 30, egli cominci a pensare ai vari modi in cui le nuovetecnologie dellepoca (radio, cinema, microfilm e televisione) potessero essere

1(Bruxelles 1868 - 1944) fu uno dei maggiori esperti moderni di bibliografia. Nel 1895fond, insieme a Henri La Fontaine, lInternational Institute of Bibliography (ora noto comeInternational Federation for Information and Documentation) e nel 1910, la Union of Inter-national Associations. Egli fu anche un attivista del movimento della pace che port, alla finedella I guerra mondiale, alla nascita della Lega delle Nazioni (e della Organizzazione per laCooperazione Intellettuale, che divent poi lUnesco).

5


6/79

combinate per fornire innovative funzioni di ricerca e analisi dellinformazione.

Innanzi tutto, pens alla possibilit di costruire, con meccanismi analogici, deisistemi che oggi chiameremmo ipertestuali: ide una stazione di lavoro costi-tuita da una scrivania che poteva accedere ad un archivio mobile, montato suruote, allinterno del quale un sistema elettro-meccanico permetteva allutentela ricerca, lettura e scrittura allinterno del database. Lutente non solo potevarecuperare documenti, ma anche annotare le loro relazioni, le connessioni checiascuno ha con tutti gli altri, formando quello che potrebbe essere chiamato ilLibro Universale. Laltro problema molto sentito era quello della decentralizza-zionedel database, che permettesse una pubblicazione o un accesso remoto allebiblioteche e centri culturali in tutto il mondo; pens quindi che gli utenti remotiavrebbero potuto accedere al database tramite un sistema (che Otlet chiamavadi teletautografia o telefotografia), connesso tramite una linea telefonica, cheavrebbe recuperato una immagine facsimile da proiettare su uno schermo della

stazione di lavoro. Infine, Otlet era convinto che il libro fosse solo un mezzoper trasmettere informazione, e che nuove tecnologie audio e video su pellicolee dischi fonografici, trasmissioni broadcast di libri e documenti, ecc. potesserodiffondere le informazioni in modo anche pi efficiente e completo.

Nonostante il lavoro di Paul Otlet sia stato completamente dimenticato finoalla sua riscoperta degli anni 90, possiamo senza dubbio dire che nonostantele limitazioni tecnologiche dei suoi tempi egli aveva gi chiaramente in menteluniverso ipermediale oggi costituito dal web.[2]

2.1.2 Vannevar Bush

Uno dei decisivi passi nella formulazione del concetto di ipertesto costituitodalle proposte contenute in quellarticolo fondamentale - "As We May Think diVannevar Bush2, che tanto influenz i ricercatori tecnologici da quel momentoin avanti. Parlando dei dati organizzati in ordine alfabetico o comunque struttu-rati in modo rigido, Bush scrisse: La mente umana non lavora in questo modo.Essa opera in modo associativo. Avendo afferrato un concetto, essa salta istan-taneamente al prossimo che viene suggerito dallassociazione di idee, in accordocon qualche intricata ragnatela di percorsi tracciata dalle cellule del cervello.

E per emulare in modo meccanico questo tipo di funzionamento, o almenoper supportarlo, Bush concep e propose il memex, un dispositivo personale aforma di scrivania sul cui piano vi sono schermi su cui possono essere proiettati imicrofilm, una tastiera, un insieme di leve e bottoni. Allinterno della scrivania vi un sistema elettromeccanico che pu gestire in modo automatico una libreriache 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 leimmagini contenenti le informazioni volute.

Ma se pur innovativo nelle capacit, uno strumento che si limiti a memoriz-zare e ricercare informazioni ancora convenzionale dal punto di vista filosofico;dove invece il memex diventa rivoluzionario sta nel fatto che permette allutentedi costruirsi un percorso personalizzato di consultazione, mediante associazioni

2Vannevar Bush fu il consigliere scientifico del presidente degli Stati Uniti F.D. Rooseveltdurante la seconda guerra mondiale, che lo nomin direttore dellOffice of Scientific Researchand Development. Durante la guerra questufficio coordin le attivit di pi di 6000 scienziatiamericani impegnati in tutte le applicazioni militari della scienza.

6


7/79

Figura 2: Vannevar Bush

Figura 3: Memex, cos come ideato da Bush

che possono essere stabilite fra le informazioni. Nel suo articolo, Bush illustred esemplific esattamente il modello che oggi noi, grazie al web, riconosciamo

7


8/79

come estremamente familiare - di ipertesto, con pagine che lutente pu navi-

gare spostandosi dalluna allaltra seguendo collegamenti che associano punti diuna pagina a punti su altre pagine semplicemente premendo un bottone sotto ilcodice corrispondente, nelle parole originali di Bush.

Per gestire questa massa dinformazioni, Bush non riusciva ancora a pensaread un computer. LENIAC, il primo elaboratore elettronico, veniva comple-tato in quegli anni, ma allepoca non era ancora lontanamente pensabile cheun dispositivo di quel genere potesse diventare sufficientemente piccolo, affida-bile e soprattutto poco costoso tanto da diventare uno strumento personale.Ma, qualunque fosse la tecnologia utilizzata per implementarlo, in As We MayThink, Bush prefigurava comunque un mondo in cui esisteva uno strumentoa disposizione delluomo, utilizzato per archiviare informazioni, connetterle fraloro in strutture metatestuali e ipertestuali, ed estrarne analisi e sintesi checostituiscano risposte alle domande che luomo si pone.

Possiamo notare come le idee di Vannevar Bush erano non dissimili da quelleviste in precedenza di Paul Otlet (del lavoro del quale forse molto probabilmentenon era a conoscenza). La differenza principale consisteva nel fatto che mentreOtlet era pi interessato a permettere allutente laccesso a sterminati databasedi informazioni remoti, e mondialmente centralizzati, Bush invece si concentravadi pi sulle funzioni a supporto del lavoro intellettuale del singolo.[2]

2.1.3 Ted Nelson

La lettura diAs We May Thinkfulmin diversi ricercatori che da quel momentocambiarono direzione ai propri studi, ed in modo indipendente dedicarono ilresto della propria attivit di ricerca al tentativo di dare vita alla visione di Bush.Il primo di questi stato Theodore Holm Nelson3, che possiamo considerareil pi grande evangelista del concetto di ipertesto. Egli fond allinizio deglianni 60 e per decenni svilupp il progetto Xanadu, che avrebbe dovuto portareallo sviluppo di un sistema per organizzare su scala mondiale informazioni inuna struttura ipertestuale e ipermediale. Egli concep Xanadu come un nuovomondo di media interattivi, una fusione di letteratura e films, basata su costruttiarbitrari, interconnessioni e corrispondenze.

Fu proprio Nelson linventore nel 1965 del vocabolo"ipertesto", a cui davail significato di sistema di organizzazione di informazioni - testuali e non - inuna struttura non lineare, elastica e non rigida. Una struttura che non potevaessere mostrata in modo convenzionale su una pagina stampata, ma che richie-deva le capacit di un computer per mostrarla in modo dinamico e navigarlaopportunamente. Nel suo intervento alla 20a conferenza dellACM, egli dichia-

rava la sua totale adesione alla visione del memex di Bush, e descriveva unsistema di strutturazione dei files dati chiamatoELF, Evolutionary List Fi-le- che rifletteva proprio lorganizzazione ipertestuale. Nello schema di Xanadu,un database di documenti universale (docuverse) avrebbe permesso lindirizza-mento di qualsiasi frammento di qualsiasi documento; in pi Xanadu avrebbemantenuto ogni versione di ogni documento (impedendo quindi i problemi dicollegamenti interrotti tipici del web - che oggi ben conosciamo).

3 (17 giugno 1937) un sociologo, filosofo e pioniere dellinformatica statunitense. Gli siattribuisce il conio di termini quali ipertesto,ipermedia. Questultimo svincola il collegamentotra contenuti informativi dai soli dati testuali.

8


9/79

Figura 4: Theodore Holme Nelson

Negli anni Nelson matur una particolare attenzione ai problemi di pro-priet intellettuale che inevitabilmente sorgono, quando dei documenti originalivengono 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 transclu-sioneche permettesse la citazione di un frammento di documento senza doverpagare diritti. Purtroppo, come molti visionari, Nelson un perfezionista chenon riesce mai ad accontentarsi di una buona soluzione, ma ha sempre cercatolottimale, che implementi in modo integrale (oggi diremmo, integralista) i suoiconcetti, senza mezze misure. Egli ritiene, fra laltro, che i collegamenti fra ivari punti del web debbano essere obbligatoriamente bidirezionali, e che nondebbano essere incorporati dentro il testo stesso, ma debbano essere conservatiin una struttura parallela come in un file system. A causa della ricerca da partedi Nelson della soluzione ottimale, nei quarantanni della sua vita Xanadu ha su-

9


10/79

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 puristadellipertesto assoluto, e propone in download un sistema inutilizzabile.

In effetti, pi che come tecnologo, Ted Nelson ha avuto successo comeevan-gelizzatoredel modello ipertestuale. In questo modo, ha spinto diverse aziendee altri enti a produrre applicazioni reali, le quali hanno ereditato da Xanadumoltissime 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 quel-le ideali per memorizzare informazioni non strutturate e molto parcellizzate eraTim Berners-Lee, che lavorava alCERNdi Ginevra come consulente e program-

matore; durante i suoi anni in Svizzera, egli si era concentrato sulle tecniche dimemorizzazione delle informazioni prodotte non solo al CERN, ma in tutto ilmondo in modo che fosse possibile ritrovarle e rivederle secondo modalit nonlineari e non predefinite.

Figura 5: Tim Berners Lee

10


11/79

Tra giugno e dicembre del 1980, Berners-Lee scrisse un programma per ge-

stire le annotazioni, chiamato Enquire Within Upon Everything4

, che girava suun computer Norsk Data sotto sistema operativo SINTRAN-III.Enquire permetteva di impostare dei collegamenti tra nodi arbitrari allinter-

no delle pagine di annotazione; ciascun nodo aveva un titolo, una tipologia, euna lista di collegamenti bidirezionali associati. Esso venne usato da vari gruppidi ricerca, ma non ebbe una diffusione significativa al di fuori del CERN.

Nel 1989 Berners-Lee scrisse un memorandum - che ormai diventato partedella storia di Internet - in cui proponeva un modello di interconnessione delleinformazioni in una struttura a ragnatela, che permettesse di navigarle in modonon lineare tramitehyper-links(ipercollegamenti). La proposta suscit un di-screto interesse e Berners-Lee, insieme a Robert Caillau, si misero al lavoro perespandere la specifica e definire tutti i meccanismi e i protocolli. La ragnateladi ipercollegamenti doveva travalicare i limiti del singolo sito, e interconnettere

tutti i siti al mondo che memorizzassero informazioni; si pens pertanto a serverdi informazioni, a cui si potesse accedere tramite un client (detto browser). Lepagine di informazioni venivano richieste dal browser al server, e il server le for-niva in un formato standardizzato chiamato HTML (Hyper-Text MarkupLanguage)e tramite un protocollo di trasferimento chiamatoHTTP (Hyper-Text 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 raggiun-gerlo, il server su cui risiedeva, il percorso allinterno del server, il nome e il tipodella risorsa in questione.

Figura 6: Architettura Client - Server

4Informati qui su qualsiasi cosa, era il titolo di un famoso manuale domestico di grandesuccesso nellInghilterra di epoca vittoriana, il cui compilatore prometteva: Che Voi Desi-deriate Modellare in Cera un Fiore; Studiare le Regole dellEtichetta; Servire una Salsa perColazione 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; Qual-siasi Cosa Desideriate Fare, Costruire o Averne Diletto, Purch il Vostro Desiderio abbiaRelazione alle Necessit della Vita Domestica, io Spero che non Falliate in Informarvi Qui"

11


12/79

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 unNeXT Cube, e Tim si mise al lavoro. Dato che la ragnatela di collegamentiera da estendere a tutto il mondo, Berners-Lee chiam il suo sistema World-WideWeb, presto abbreviato in WWW. Nel novembre del 1990, diventavadisponibile la prima pagina sul primo server HTTP della storia. Il giorno diNatale 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 (spe-cialmente fra gli istituti di ricerca collegati al CERN) e poi negli Stati Uniti enel resto del mondo. Nel gennaio del 1993 esistevano circa 50 HTTP servers nelmondo, 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 identi-ficazione e indirizzamento delle risorse nella rete;

HTTP (HyperText Transfer Protocol), protocollo client-server dialto 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

IlWWW Consortium stato fondato nel 1994 dallinventore del WWW TimBerners-Lee (vd.2.1.4) presso ilMIT (Massachussets Institute of Techno-logy)in collaborazione con ilCERN. Esso unorganizzazione non governativainternazionale che ha come scopo quello di sviluppare tutte le potenzialit delWorldWideWeb. Al fine di riuscire nel proprio intento, la principale attivitsvolta dal W3C consiste nello stabilire standard tecnici per il WorldWideWebinerenti 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:

5Lo Standard Generalized Markup Language (SGML), un metalinguaggio definito comestandard ISO (ISO 8879:1986 SGML) avente lo scopo di definire linguaggi da utilizzare per lastesura di testi destinati ad essere trasmessi ed archiviati con strumenti informatici, ossia perla 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 devonoavere i documenti di un determinato tipo. Si dice che questi documenti rispetto a SGMLcostituiscono un linguaggio obiettivo, ovvero una applicazione.

SGML dovuto soprattutto allopera di Charles Goldfarb e discende dal Generalized Mar-kup Language, linguaggio definito negli anni 1960 presso la IBM, da Goldfarb, Mosher eLorie.[9]

12


13/79

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

Systems, Google, IBM, Intel, Microsoft, Oracle, Siemens, Sony e SunMicrosystems;

compagnie telefoniche come Ericsson, Nokia, NTT DoCoMo;

societ di grandi dimensioni appartenenti ai pi svariati settori, ma stra-tegicamente interessate alla crescita del Web: American Express, Agfa-Gevaert N. V., Boeing, Chevron-Texaco;

organizzazioni non-profit come la Mozilla FoundationeThe Open Group;

universit e istituzioni per la ricerca: il CSAIL del MIT, Inria e altrimembri dellERCIM e Keio University;

altre istituzioni ospitano gli uffici nazionali del Consorzio: per lItalia l I-

STIdi Pisa del CNR; sono numerose le universit e gli istituti di ricercatra i pi prestigiosi:Academia Sinica, la Library of Congress, il Los AlamosNational Laboratory, il National Institute of Standards and Technology.

Il consorzio affidato a Tim Berners-Lee, in qualit di direttore, ed alDr. Jeffrey Jaffe, in qualit di CEO (Chief Executive Officer, amministratoredelegato).

Attori del W3C Diventare membri del W3C non , ovviamente, cosa gratuitae lamembership feevaria a seconda che si tratti di grandi compagnie o universite 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 mem-bro W3C. I compiti di tale commissione sono:

esamina i piani futuri del W3C ad ogni meeting del comitato consul-tivo;

esamina le proposte presentate dal direttore del W3C;

elegge i componenti dellAdvisory board oltre allAdvisory BoardChair (una sorta di capo-commissione);

elegge 5 dei 9 partecipanti al Technical Architecture Group.

lAdvisory Board, corpo consultivo il cui compito principale quello diprovvedere linee guida su tematiche quali strategie da adottare, manage-

ment, affari legali e risoluzione di conflitti. Precisiamo che tale organo nonpossiede potere decisionale ma solo consultivo. Vi sono 9 membri eletti dalcomitato consultivo ed un Chair(tecnicamente il direttore del gruppo).

ilTechnical Architecture Group, il cui compito , generalmente, am-ministrare le architetture Web. In dettaglio:

documenta e costituisce il consenso6 sulle principali architetture Web;6Il 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) supportanola decisione in esame e nessuno di essi solleva una obiezione ufficiale. I membri del W3Cpossiedono diritto di astensione. Il dissenso si consegue quando almeno un membro del W3Csolleva una obiezione ufficiale.

13


14/79

risolve le problematiche relative alle architetture Web;

coordina lo sviluppo di architetture cross-technology sia allinternoche allesterno del W3C.

I membri del TAG sono 8 pi un Chair (tecnicamente il direttore delgruppo). Tre componenti del TAG sono nominati dal direttore, gli altri 5dallAdvisory 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, riuniretutti 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 grup-pi allinterno come anche allesterno del W3C;

i chartered groups, costituiti dai rappresentanti dei vari membri delConsorzio e da esperti di settore, che producono la maggior parte delledelibere del W3C in accordo con il percorso che le specifiche W3C devononecessariamente seguire.

Iter delle specifiche W3C Il processo di sviluppo dei technical report con-siste nellinsieme di passi e requisiti seguiti dai gruppi di lavoro del W3C attia standardizzare le tecnologie per il Web. Tale processo caratterizzato daiseguenti 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 tecnologieroyalty-freeed interoperabili.

W3C segue i seguenti passi (Fig.7) per produrre i cosiddettiReccomendation(referenze):

pubblicazione del First Public Working Draft, cio il primo stadio diavanzamento che si consegue nel momento in cui il lavoro di un Working

Group soddisfa i requisiti minimi di avanzamento7;7Per 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 rapportotecnico rispetto alla pubblicazione precedente;

fornire, formalmente, tutte le risoluzioni ai problemi presenti nella pubblicazioneprecedente.

E evidente che per unFirst Public Working Draft non esistono versioni precedenti: nerisulta che lapprovazione a tale livello pressoch automatica.

14


15/79

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

Public Working Draft; pubblicazione di un Candidate Recommendation, cio il secondo sta-

dio di avanzamento che si consegue nel momento in cui il lavoro di unWorking Group soddisfa, in aggiunta ai requisiti minimi di avanzamento,dei requisiti aggiuntivi8;

pubblicazione di un Proposed Recommendation, cio il terzo stadiodi avanzamento che si consegue nel momento in cui il lavoro di un Wor-king Group soddisfa, in aggiunta ai requisiti minimi di avanzamento, deirequisiti aggiuntivi9;

pubblicazione di un W3C Recommendation, cio lo stadio ultimo diavanzamento che si consegue nel momento in cui il lavoro di un Wor-

king Group soddisfa, in aggiunta ai requisiti minimi di avanzamento, deirequisiti aggiuntivi10

I Working Group Notes, Member Submissions, Staff Comments,Team Submissionsnon 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 recensiscala specifica (almeno 28 giorni dopo la pubblicazione del Proposed Recommendation). Inaggiunta 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 CandidateRecommendation siano state formalmente esposte;

mostrare tutte le problematiche venute alla luce dopo la fase di CandidateRecommendation

. Il direttore deve:

annunciare la pubblicazione di un Proposed Recommendation allAdvisory Committeee pu, a sua discrezione, approvare un Proposed Recommendation con una esperienzaimplementativa 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 ReccomandationallAdvisory Committee, ai gruppi del W3C e al pubblico.

15


16/79

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 con-sente allutente di navigare le pagine Web mediante collegamenti ipertestuali. Iprimi browser, sorti nei primi anni 90, erano solo testuali con conseguente bassausabilit da parte dellutente finale. Solo nel 1992 viene realizzato il primo bro-wser grafico comandato via mouse,Mosaic, mediante il quale inizia lesplosione

della popolarit del WWW.Levoluzione tecnologica stata a lungo rallentata dalla cosiddetta browserwarche ha visto contesi i browser Internet Explorer e Netscape. Negli ultimianni, 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 evidenziatonella Fig.9 essi sono:

User Interface, il layerpresente fra lutente e il browser engine.Regola funzionalit quali le toolbar, progresso nel caricamento della pa-gina, gestione intelligente dei download, opzioni preferite e stampa. Puessere 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 nuovefunzionalit nella navigazione o nella gestione dei dati utente;

barra di ricerca personalizzabile;

supporto allinterazione mediantegesti;

maggior risalto a potenziali rischi per la sicurezza (connessioni nonsicure, phishing, etc.).

Browser Engine, implementa uninterfaccia di alto livello verso ilRen-

dering Engine. Permette di caricare un URI e supporta le azioni primi-tive del browser qualiforward, back e reload. Inoltre funge da "aggancio"per consentire la visione di aspetti eterogenei della sessione corrente delbrowser come la percentuale di caricamento della pagina o gli eventi Java-Script. Consente di gestire i plugin, quei componenti aggiuntivi che per-mettono di visualizzare particolari contenuti incorporati nelle pagine Web(generalmente contenuti multimediali e interattivi per RIA - Rich Inter-net Applications11) Infine consente ilqueryinge la modifica dei parametridel Rendering Engine;

11 Applicazioni web che possiedono le caratteristiche e le funzionalit delle applicazionidesktop, senza per necessitare dellinstallazione sul disco fisso.

16


17/79

Rendering Engine, fornisce una rappresentazione visuale per un URI

dato. Consente di visualizzare documenti redatti in HTML e XML, op-zionalmente realizzati mediante CSS, cos come contenuti embeddedqualile immagini. Calcola il corretto layoutdella pagina e pu adoperare algo-ritmi di reflowper modificare dinamicamente la posizione degli elementinella pagina. Gestisce le interazioni dellutente e passa gli eventi generatialJavaScript interpreter.

In tale sottosistema presente il parser HTML.

Recenti innovazioni in tale sottosistema sono:

separazione dei processi: il processo del browser enginecrea un nuo-vo processo per il rendering enginedi ogni tab (pagina) aperto. No-nostante ci comporti un leggero incremento duso delle risorse, si

impedisce a crashdi sistema o a violazioni di sicurezza, verificatesisu di una pagina, di impattare sulle altre.

Networking, implementa protocolli di trasferimento file quali HTTP eFTP. Traduce i differenti insiemi di caratteri e risolve i tipiMIMEper i file.Pu anche implementare unacachedelle risorse recentemente recuperate;

JavaScript Interpreter, valuta il codice JavaScript (anche chiamatoECMA-Script12) che pu essere incluso nelle pagine web. JavaScript un linguaggio di scripting object-oriented sviluppato da Netscape. Alcu-ne funzionalit JavaScript, quali aprire finestre di pop-up, possono esseredisabilitate dal Browser Engine o dal Rendering Engine per ragioni disicurezza.

Recenti innovazioni in tale sottosistema sono: 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 riu-so delle parti gi compilate, le prestazioni possono miglioraresensibilmente rispetto ad un interprete puro.

Figura 8: Motori JavaScript con JIT Compiler

12EuropeanComputerManufacturersAssociationScript un linguaggio di scripting standar-dizzato dalla ECMA International nella specifica ECMA-262 e nellISO/IEC 16262. Si trat-ta di un linguaggio largamente adoperato per lo scripting client-side nella forma di famoseimplementazioni quali JavaScript, JScript e ActionScript.

17


18/79

XML Parser, effettua il parsingdei documenti XML in un alberoDOM.

E il sottosistema pi riadoperato dellintera architettura poich conve-niente riadoperare un parser XML esistente piuttosto che ricrearlo da zero.I documenti elaborati possono essere scambiati con i Web server medianteparadigmaAJAX;

Display Backend, consente di adoperare primitive legate al disegno ealle finestre, di adoperarewidgete fornisce un insieme di font. Pu essereaccorpato al sistema operativo.

Recenti innovazioni in tale sottosistema sono:

Accelerazione hardware: sono sfruttate le istruzioni dedicate mes-se a disposizione dalle recenti generazioni di hardware grafico al finedi:

migliorare la qualit di immagini e testo e la fluidit di scorri-mento;

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 sufile systemdifferenti dati associati allasessione di browsing corrente. Si tratta di dati di alto livello, quali isegnalibrio settaggi delle toolbar, oppure dati di basso livello, qualicookie,certificati di sicurezza, cache.

Recenti innovazioni in questo sottosistema sono:

uso di database embedded (SQLite) per maggiore efficienza e scala-bilit;

sincronizzazione dei dati (mediante server remoto) tra calcolatoridiversi associati allo stesso utente.

Figura 9: Architettura di un Web browser

LHTML parser inserito di proposito nel sottosistemarendering engineri-spetto al parser XML poich questultimo un componente generico e riusabile

18


19/79

Figura 10: Differenti tipi di rendering engine

costituito da una interfaccia ben definita mentre il primo, per ragioni di per-formance e di interpretazione di codice HTML non standard, preferibile siaintegrato in un sottosistema di render.

Architettura di Mozilla Firefox La suiteMozilla(Fig.11) stata rilasciatacome open sourceda Netscapenel 1998. Da allora la maggior parte dei sistemiche la compongono sono stati riprogettati e riscritti, con conseguente aggiuntadi 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 del-linterfaccia utente siano realizzate in JavaScript (alcune componentilegacysonoscritte in C). Il sottosistema User Interface suddiviso in due sottosistemi cosda garantire il loro riutilizzo in altre applicazioni della suite Mozilla come, adesempio, client di mail o news.

Tutte le operazioni didata persistencesono svolte dal meccanismo di profila-zione 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 partedegli altri browser: una motivazione costituita dalla capacit di Mozilla dieffettuare correttamente ilparsinge ilrenderingdi pagine HTML malformate oerrate. In aggiunta a ci, il rendering engine si occupa di renderizzare le inter-facce utente cross - platform. La UI , infatti, specificata nel linguaggioXUL(Extensible User Interface Language), che mappato da apposite librerie speci-fiche a seconda della piattaforma adoperata dallutente finale. Il core di Mozilla stato reingegnerizzato in un componente runtimedenominato XULRunneril quale consente ad altre applicazioni di sfruttare i sottosistemi browser. Ciconsente agli sviluppatori di adoperare le moderne tecnologie web per realizzareapplicativi molto pi elaborati delle consuete applicazioni browser - based.[1]

19


20/79

Figura 11: Architettura del browser Mozilla Firefox

Proxy based browser E un tipo di architettura (Fig. 25) in cui il brow-ser non accede direttamente alle risorse sul Web, ma tutte le richieste vengo-no filtrate da un proxy server (gestito dal fornitore del browser) affinch siapossibile:

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 dallerisorse di calcolo limitate (cellulari).

Figura 12: Architettura di un proxy - browser

Generalmente il tempo complessivo di caricamento di una pagina Web (turnaroundtime) pari a:

T=Lcs+ Tcs + S+ C (1)

dove:

Lcs, rappresenta la latenza di connessione client - server di origine;

20


21/79

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 browserproxy - based , invece, pari a:

T =Lcp+ Lps+ Tcp+ Tps+ S +C (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 < Tdati i seguenti accorgi-menti:

Lcp, Lps


22/79

Figura 13: Pila TCP/IP

3 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 tuttele richieste effettuate tramite protocollo TCP vengono, di default, trasmessemediante porta 80.

HTTP presenta due caratteristiche basilari. Esso infatti:

generico, cio indipendente dal formato dati con cui vengono trasmesse lerisorse. 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 persi-stano tra una connessione e la successiva sulla natura, identit e precedentirichieste effettuate da un client. Il client tenuto a ricreare da zero il con-testo necessario al server per rispondere. Riassumendo: non vi memoriadelle richieste effettuate.

Figura 14: Schema di funzionamento del modello client - server

22


23/79

3.3 Versioni di HTTP

HTTP esistito in tre versioni:

0.9, protocollo client - server di sola richiesta di risorse HTML, senzaflessibilit n nella direzione, n nel formato delle risorse. Consente lusoesclusivo del metodo di richiesta GET;

1.0, prima versione standard. Protocollo generico e privo di stato me-diante 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 persisten-ti.[4][5][3][6]

3.4 Entit

Analizziamo lo scenario di applicazione di una connessione HTTP evidenzian-done gli attori:

Client, applicazione che richiede una connessione HTTP, con lo scopo diinviare richieste;

Server, applicazione che accetta connessioni HTTP e genera risposte;

User agent, client che inizia una richiesta HTTP. Tipicamente un bro-wser, ma pu anche essere un bot13 o un altro tool come ad esempiocurl14;

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 ser-ver. A differenza del proxy, il gateway riceve le richieste come fosse lo-rigin server: il client pu essere alloscuro che si tratti effettivamente delgateway;

Tunnel, programma intermediario che agisce da trasmettitore passivo diuna 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 mec-

canismi della sua gestione ed aggiornamento. Qualunque client o serverpu utilizzare una cache.

13Abbreviazione dirobot. Si tratta di unapplicazione automatica che richiede e scarica pagi-ne HTML e siti web per scopi quali lindicizzazione, la catalogazione, laverifica di correttezzasintattica. E uno user agentanche se non serve direttamente utenti.

14ClientURLRequestLibrary un software, composto da una libreria e da un tool in rigadi comando, il cui scopo quello di trasferire dati adoperando differenti protocolli. Il cURLproject si compone di due prodotti, libcurl e cURL. E stato rilasciato per la prima voltanel 1997. I protocolli supportati sono: HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP,LDAP, LDAPS, DICT, TELNET, FILE, IMAP, POP3, SMTP,RTSP.[12]

23


24/79

3.5 Struttura dei messaggi HTTP

I messaggi HTTP seguono la Backus - Naur Form.

3.5.1 Backus - Naur Form

LaBNF(Backus-Naur Formo Backus Normal Form) unametasintassi, ovve-ro un formalismo attraverso il quale possibile descrivere la sintassi di linguaggiformali (il prefissometaha proprio a che vedere con la natura circolare di questadefinizione). Si tratta di uno strumento molto usato per descrivere, in modo pre-ciso e non ambiguo, la sintassi dei linguaggi di programmazione, dei protocollidi rete.

In termini formali, la BNF pu essere vista come un formalismo per descri-vere grammatiche libere dal contesto.

La BNF fu proposta daJohn Backusnel corpo della definizione del linguag-gio di programmazioneALGOL. Lacronimo BNF era inizialmente inteso comeBackus Normal Form ("forma normale di Backus"); su suggerimento di DonaldKnuth, fu in seguito riletto come Backus-Naur Form, in onore diPeter Naur, unaltro 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 espressanella forma:

< simbolo >::=_espressione_o nella forma equivalente:< simbolo >_espressione_Le due forme sono assolutamente equivalenti. La prima forma (che verr

utilizzata nel seguito) utilizza caratteriASCII standarded quella pi utilizzata

per scrivere grammatiche che devono essere utilizzate dai calcolatori e lette in filedi testo. La secondaforma meno utilizzabile nella pratica ma comune neitesti e negli articoli di informatica teorica in quanto meglio esprime loperazionedi derivazione delle stringhe di un linguaggio a causa dellapplicazione delleregole di derivazione.

Nelle regole di derivazione(i caratteri< e > sono obbligatori)viene detto un simbolo nonterminale e _espressione_ costituita da unao pi sequenze di simboli terminalio nonterminali(identificati dal fatto diessere racchiusi tra < >); se le sequenze sono pi di una esse sono separatedalla barra verticale |. La regola esprime il fatto che il nonterminale a sinistradella regola pu essere sostituito da una qualsiasi delle sequenze indicate sulladestra. Inoltre in una sequenza alcuni simboli o sottosequenze possono essere

indicati comeopzionaliracchiudendoli fraparentesi quadre.I simboli che non appaiono mai a sinistra di una regola di derivazione sonodetti terminali. I terminali sono in un certo senso il punto di arrivo, perch rap-presentano elementi che si troveranno effettivamente in un testo scritto secondole regole sintattiche che la specifica BNF descrive. I simboli nonterminali, vice-versa, sono strumenti utilizzati esclusivamente dalla BNF e sono racchiusi tra ; si pu dire che essi rappresentano gli elementi astrattidella grammatica.

BNF rules Le seguenti regole sono usate nella descrizione dei messaggi HTTP:

OCTET =

24


25/79

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

UPALPHA =

LOALPHA =

ALPHA = UPALPHA | LOALPHA

DIGIT =

CTL =

CR =

LF =

SP =

HT =


26/79

3.5.2 HTTP: tipologia messaggi

I messaggi HTTP (versione 1.1) consistono inrichiesteda un client ad un servered in risposteda un server ad un client:

HTTP-message = Request | Response.

Entrambi i tipi di messaggio contengono una start - line, zero o piheaderfield(header), una linea vuotache attesti il termine degli header field e unmessage - 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 ri-cevute al posto di una Request - Line. In altre parole, se il server legge il flussodati 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 headerconsiste di un nome seguito dai due punti (:) a cui segue ilvaloreattribuito al campo.

I campi sono case - insensitive.I valori possono essere preceduti da un numero imprecisato di (LinearWhite

Space, spazi vuoti lineari)(vd. 3.5.1) anche se preferibile inserire un singoloSP(vd. 3.5.1). Gli header fieldpossono estendersi su pi righe a patto checiascuna rigaextrasia preceduta da un SPo 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 comunica-zione per permettere la spedizione tramite e-mail (e, per estensione, sul Webtramite HTTP) di dati binari codificati.

A ciascun flusso di dati associata una intestazione del tipo Content-type:object/formatdove:

objectspecifica il tipo di oggetto codificato (text, image...);

formatindica il formato con cui strutturato (ad esempio, per un oggettotext pu essere plain, html);

26


27/79

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 iltipo generico application/octet-stream.

MIME nato perch i sistemi basati suSMTP15 trasportano correttamenteal pi i primi 128 caratteri del codiceASCII(caratteri alfanumerici), mentre al-linterno di un file binario i byte possono avere tutti e 256 i valori possibili; quindi necessario prevedere un sistema di codifica. Content-Transfer-Encodingindica la codifica da adoperare per la spedizione delloggetto. MIME prevedealcune codifiche standard:

7 bit, nessuna operazione di codifica stata effettuata sul contenuto del

messaggio. In questo caso i dati possono essere rappresentati in gruppi disette bit, ognuno dei quali rappresenta un carattere ASCII; questo ancheil valore assunto come default se il campo non viene specificato;

8 bit, nessuna operazione di codifica stata effettuata sul contenutodel messaggio. Possono essere presenti caratteri non appartenenti al setASCII; cio, suddividendo il messaggio in linee di 8 bit ciascuna e asso-ciando ad ogni linea un carattere ASCII, si possono ottenere delle sequenzedi caratteri apparentemente senza significato;

binary, nessuna operazione di codifica stata effettuata sul contenuto delmessaggio. Il contenuto del messaggio in formato binario (unimmagine,un file audio, ecc.);

quoted-printable, indica che unoperazione di codifica gi stata ap-plicata ai dati, in modo da trasformare il messaggio in una sequenza dicaratteri ASCII (se il messaggio originario era gi costituito da un te-sto ASCII, questa codifica lo lascia sostanzialmente inalterato). Lo scopoprincipale di questa codifica di mettere i dati in un formato che difficil-mente subir delle trasformazioni da parte dei vari sistemi che costrettoad attraversare, prima di giungere a destinazione;

base64, indica che sui dati stata effettuata unoperazione di codifica,dettabase64. Con questa operazione il messaggio viene trasformato in unasequenza di caratteri appartenenti ad un sottogruppo del set di caratteriASCII (le lettere maiuscole da A a Z, quelle minuscole da aa z, i numerida0 a 9, il carattere+ ed il carattere\). In questo modo, ogni caratterecodificato pu essere rappresentato con sei bit. Loperazione di codificaconsiste nel suddividere la sequenza dei bit in ingresso (il messaggio) ingruppi di 24 bit; ogni gruppo di 24 bit viene diviso in quattro gruppi disei bit, ad ognuno dei quali si associa il corrispondente carattere ASCIIappartenente al sottogruppo specificato.

[7]

15SimpleMail Transfer Protocol (SMTP) il protocollo standard per la trasmissione viainternet di e-mail

27


28/79

3.5.5 HTTP: Body

Ilmessage - body(se presente nel messaggio HTTP) adoperato per trasferirelentity - body associato alla richiesta o alla risposta. Message - body eEntity - body differiscono tra loro solo se applicata qualche codifica nellatrasmissione (transfer - coding):

message-body = entity-body | .

La presenza di unmessage - bodyin unarichiesta segnalata dalla presenzadellheader Content - Length o Transfer - Encoding. Un message - bodynon deve essere incluso in una richiesta se il metodo adoperato non permette,secondo le specifiche, di inviarne uno. Se esso viene inserito ugualmente, no-

nostante il metodo adoperato lo vieti, il server ignorer il message - body nelmomento in cui analizzer la richiesta stessa.t.

La presenza di un message - body in una risposta dipendente sia dalmetodo delle richiesta che dallo status code della risposta. Ad esempio tut-te le risposte al metodo HEAD non includeranno un message - body. E, allostesso modo, tutte le risposte con status codepari a 1xx (informational, in-formativa), 204 (no content, nessun contenuto) e 304 (not modified, nonmodificato). Tutte le altre risposte necessitano di message - bodyanche se essofosse di lunghezza zero (zero length).

3.5.6 HTTP: Message Length

Iltransfer - lengthdi un messaggio dato dalla lunghezza delmessage - bodycos come appare nel messaggio dopo che siano state applicati eventualitransfer- coding.

Quando unmessage - 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 - bodyterminasempre con la prima linea vuota presente dopo gli header field;

se presente un header transfer - encodinge ha un valore differente dalli-dentit, allora il transfer - length calcolato mediante il chunked transfer- coding16, a meno che il messaggio sia terminato dalla chiusura dellaconnessione;

se presente lheader Content - Length, il valore decimale del suo ottettorappresenta sia lentity - lengthche il transfer - length;

se il messaggio adopera il tipo multipart/byteranges, e i l transfer -lengthnon altrimenti specificato, allora lo stesso tipo multipart adindividuare il transfer - length;

il server che lo calcola chiudendo la connessione.16 Il chunked encodingmodifica il bodydi un messaggio cos da trasmetterelo mediante

una serie di chunk(spezzoni), ciascuno con un proprio indicatore di grandezza e seguito dauna coda (opzionale) per eventuali header.

28


29/79

Per ragioni di compatibilit con HTTP/1.0, le richieste effettuate con HTTP/1.1

contenenti un message - bodydevono includere un Content - Length valido ameno che non si sappia a priori che il server a cui indirizzato il messaggiorispetta lo standard 1.1.

3.5.7 HTTP: Header generici

Ci sono alcuni header che possono essere applicati sia per richieste che perrisposte e che non riguardano direttamente la particolare entit da trasferire:

Cache - Control, usato per specificare le direttive a cui devono soggia-cere tutti i meccanismi di caching. Ci per garantire che i meccanismi dicaching non interferiscano con la trasmissione del messaggio. Le direttivedi caching sonounidirezionalicio 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 esempioquando inoltrata la direttiva no-cachela richiesta deve essere inoltratadirettamente allOrigin server;

Trailer, indica che linsieme degli header field presente nella coda delmessaggio codificato mediantechunked transfer - coding;

Transfer - Encoding, usato per specificare leventuale codifica dei datiapplicata al message - body;

Upgrade, consente al client di specificare quali protocolli addizionali essosupporta e consente al server di effettuare lo switchingfra essi qualora loritenesse opportuno;

Via , generalmente adoperato dai gateway e dai proxy per indicare iprotocolli e gli attori intermediari posti fra lo user agent e il server in unmessaggio di richiesta, e fra lorigin server e il client in un messaggio dirisposta;

Warning, adoperato per trasferire informazioni addizionali in meritoallo stato o alla trasformazione di un messaggio che potrebbe non evincersidal messaggio stesso.

3.5.8 HTTP: Header field dellentit

Essi danno informazioni circa il bodydel messaggio, o, in sua assenza, sullarisorsa specificata. Nello specifico:

Content - Type, indica il tipo MIME dellentit acclusa. Questo header obbligatorio in ogni messaggio che abbia un body;

29


30/79

Content - Length, indica la lunghezza in bytedel body. Obbligatorio in

ciascun messaggio che disponga di un body; Content - Encoding, Content Language, Content Location, Con-

tent - MD5, Content - Range, indicano, rispettivamente, la codifica, illinguaggio, lURL della risorsa specifica, il valore di digest MD5 e il rangerichiesto della risorsa;

Expires, indica la data dopo la quale la risorsa non considerata pi va-lida e deve necessariamente essere richiesta nuovamente allorigin server;

Last - Modified, la data e lora dellultima modifica. Serve per deciderese 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 includenella prima linea del messaggio stesso:

metododa applicare alla risorsa in trasmissione;

URIdella risorsa in trasmissione;

protocol versionin uso.

Figura 15: Messaggio di richiesta

Request - Line Larequest - line, come su visto, incomincia con un metodo,segue con lidentificativo univoco URI della risorsa e termina con la versionedel protocollo HTTP adoperata: i tre campi sono intervallati fra loro da unSP(vd.3.5.1) e non possono contenere CRLF(vd.3.5.1) fatta eccezione per iltermine della request - line.

Metodi Il campoMethodindica il metodo da adoperare sulla risorsa identi-ficata dalRequest - URI. I metodi sono case - insensitive. Inoltre un metodoHTTP pu essere:

sicuro, non genera cambiamenti allo stato interno del server;

idempotente, leffetto di una stessa richiesta su pi server lo stesso diquello generato su pi server.

Essi sono:

30


31/79

OPTIONS, rappresenta una richiesta di informazioni riguardo le opzioni

di comunicazione adoperabili sulle interazioni client - server identificate dalrequest - uri; nel dettaglio il metodo permette al client di determinare leoperazioni o i requisiti associate ad una risorsa, le caratteristiche del server,senza effettuare, di fatto, una operazione di resource action (modifica ocancellazione di una risorsa) o resource retrieval (scaricamento di unarisorsa);

GET, consente di recuperare qualsiasi informazione (sottoforma dientit)sia identificata da un URI. La semantica del GET cambia a seconda chesi 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-None-Match, If-Range (vd. 3.5.9). Un GET condizionale richiede cheunentit sia trasferita solo date le condizioni contenute negli even-tuali header. Lutilit consiste nella riduzione dellutilizzo di banda,consentendo, ad esempio, il refreshingdi una risorsa mediante cachepiuttosto che tramite richieste multiple.

parziale, se il messaggio include un header Range (vd.3.5.9). UnGET parziale richiede solo ed esclusivamente la parte dellentit ri-chiesta dallheader. Lutilit risiede nella possibilit di ridurre lu-tilizzo di rete. Ad esempio, in caso di entit parzialmente scarica-te possibile adoperare un GET parziale per non dover trasferirenuovamente i dati gi posseduti dal client.

HEAD, identico al GET fatta eccezione per il fatto che il server nondeve restituire un message - body. E spesso adoperato per testare

lavaliditdi un URI, cio la risorsa esiste e non di lunghezza zero;

laccessibilitdi un URI, cio la risorsa accessibile presso il servere non sono richieste procedure di autenticazione del documento;

la coerenza di cache di un URI, cio se la risorsa non statamodificata nel frattempo, non ha cambiato lunghezza, valore hash odata di modifica.

POST, utilizzato per richiedere allorigin server di accettare lentitallegata alla richiesta come una subordinata (aggiuntiva) alla risorsa

(generalmente preesistente) indicata nellURI della richiesta. Esempi tipicisono:

annotazione di risorse preesistenti;

postare un messaggio su un forum, su un newsgroup, in una mailinglist o simili;

effettuare il submit di un form;

estendere un database attraverso una operazione di append.

POST non sicuron idempotente.

Il server pu rispondere ad una richiesta POST in tre modi:

31


32/79

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 specifi-cata; non presente un body nel messaggio di risposta.

PUT, richiede che lentit racchiusa nel messaggio di richiesta sia me-morizzata nellURI indicato. Nel caso in cui lURI punti ad una risorsagi esistente questultima sar sostituita dalla nuova, altrimenti ne verrcreata una nuova.

In caso di creazione di una nuova risorsa, lorigin serverdeve necessaria-mente informare lo user agentmediante codice 201 CREATED. Se una

risorsa preesistente stata modificata il codice di risposta dovr essere200 OKoppure204 NO CONTENT.

Nel caso in cui una risorsa non possa essere correttamente creata o mo-dificata presso lURI indicato nella richiesta, il server deve comunicare unopportuno messaggio di errore che rifletta la natura del problema.

La differenza fondamentale fra POST e PUT risiede nella diversa inter-pretazione data allURI. Questo nel caso del metodo POST identifica larisorsa che gestir lentit inclusa nella richiesta, mentre nel metodo PUTesso identifica la risorsa stessa su cui si andr ad operare (e, di conse-guenza, il server non potr applicare la richiesta a qualche altra risorsadifferente da quella indicata nellURI).

PUT idempotente ma non sicuro, non offre alcuna garanzia in terminidi controllo degli accessi o locking.

DELETE, richiede che lorigin serverelimini la risorsa indicata nellURI.Il client non pu essere certo che loperazione sia andata a buon fine poichsi tratta di un metodo che possibile modificare (override) manualmentesulla macchina server.

TRACE, adoperato per invocare un messaggio di loop - back delmessaggio di richiesta. Tale metodo permette al client di osservare cosaeffettivamente ricevuto al termine della catena di richiesta ed effettuare,di conseguenza, valutazioni prestazionali e testing.

CONNECT, adoperato mediante connessione proxye permette di ef-

fettuare loswitching in un tunnel17

.

Header Gliheaderdi un messaggio di richiesta vengono acclusi dalclientperspecificare informazioni sulla richiesta e su s stesso al server. Essi sono:

User - agent, una stringa che descrive il clientche origina la richiesta;tipicamente contiene

17Tecnica utilizzata nel campo della trasmissione di dati digitali per veicolare informazioniche normalmente utilizzano altri protocolli, attraverso lo standard HTTP (creando cio un"tunnel" attraverso la connessione Http). Tale tecnica viene utilizzata anche per bypassare ifirewall, utilizzando tipologie di connessioni non bloccate per effettuare altre operazioni chenormalmente verrebbero filtrate.

32


33/79

tipo;

versione del browser; sistema operativo;

Referer, consente di:

indicare lURL della pagina che ha condotto lutente alla nuova ri-sorsa;

controllare i percorsidegli utenti al fine di operare politiche di userprofiling18 o pubblicit.

Nel caso in cui una risorsa sia richiesta senza lutilizzo di link taleheadernon deve essere trasmesso.

Dovrebbe chiamarsiReferrerma la dizione attuale deriva da una impro-pria compitazione (spelling) effettuata nel 1996 da parte dellinformaticoPhillip Hallam - Baker che appose la parola priva della doppia r nelRFC1945. Lerrore rimasto incorretto poich allepoca lo Unix spellchecker non riconosceva come parole di senso compiuto sia REFERERcheREFERRER;

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 - basedvirtual hosting poich non richiede manipolazioni del routing o

multi - addressing IP). Se un servercontiene pi siti Web per scopidiversi,Hostconsente alserverdi distinguere il sito a cui la richiestafa riferimento;

From, indica la e - mail del richiedente. Si richiede che lutente dia lasua approvazione prima di inserire questo headernella richiesta;

Authorization, Proxy - Authorization, indica una stringa di autoriz-zazione per laccesso ad una risorsa;

Range, richiede non lintera risorsa ma solo una sua parte specificata comeuna sequenza dibyte range(vd. Fig.16). E adoperato principalmente daidownload managerper riprendere download interrotti senza recuperare la

totalit del file in scaricamento; Accept, Accept - Charset, Accept - Encoding, Accept Language,

indicano limplementazione della negoziazione del formatoper ci cheriguarda, rispettivamente:

tipo MIME;

codice caratteri;

codifica MIME;

lingua umana.

33


34/79

Figura 16: Esempio di richiesta con header Range

Il clientnella richiesta specifica cosa sia in grado di accettare e il servernella risposta offre il matchpi consono. E presente un quality factortramite cui possibile comunicare il valore di preferenza mediante numerireali compresi fra 0 (preferenza minima) ed 1 (preferenza massima, valorepredefinito).

Ad esempio la figura 17 comunica al server quanto segue: "Preferiscotext/htmletext/x-c, ma se non esistono mandami la risorsa in formatotext/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 con-dizionali (cfr. sez. 3.5.9) nelle quali il metodo HTTP eseguito solose la condizione risulta vera (vd. 18). Possono verificarsi le seguentieventualit:

se la richiesta, a meno della condizione, d luogo ad una risposta

diversa dallo status200 (OK), o la data non valida, questi headersono ignorati;

se la richiesta, a meno della condizione, d luogo ad una risposta constatus 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 constatus 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:

laprimaindica la classe;

le altre due la risposta specifica.

18Informazioni associate ad uno specifico utente. Un profilo si riferisce, quindi, alla esplicitarappresentazione digitale dellidentit di una persone e pu essere adoperato da sistemi chetengano conto delle preferenze del soggetto stesso.

34


35/79

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 larichiesta;

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 sod-disfatta per un errore da parte del client (errore sintattico o richiesta nonautorizzata);

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 Ciascunostatus code accompagnato da una descrizione peresteso 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 lURLnon valido e il server conosce lanuova 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;

19In informatica Common Gateway Interface, una tecnologia standard usata dai webserver per interfacciarsi con applicazioni esterne generando contenuti web dinamici. Ognivolta che un client richiede al web serverun URL corrispondente ad un documento in puroHTML gli viene restituito un documento statico (come un file di testo); se lURL corrispondeinvece ad un programma CGI, il serverlo esegue in tempo reale, generando dinamicamenteinformazioni per lutente.

35


36/79

404 Not found, se lURL errato;

500 Internal server error, rappresenta, tipicamente, un bug in unCGI;

501 Not implemented, se il metodo richiesto non conosciuto dalserver.

Header Gli headerdella risposta sono posti dal serverper specificare infor-mazioni 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 valoriprevisti sono:

byte, opzionale. I client possono generare richieste di tipo byte -range senza aver ricevuto questo header;

none, vieta al clientdi 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 acces-

so, il serverrichiede lautenticazione dellutente. Al metodo GET fornita larisposta 401 (Unauthorized), pi un header WWW - Authenticate chespecifica i criteri con cui autenticarsi. HTTP ha due metodi di autenticazione:Basic access authentication (introdotto in HTTP 1.0)e Digest accessauthentication (introdotto in HTTP 1.1).

Basic access authentication Lautenticazione basic basata sullinvio, daparte delclient, di unauser-IDe di unapasswordper ciascunrealm20. Ilserveresaudir la richiesta solo se user-ID e password risultano essere validi per lospecifico spazio di protezione dellURI richiesto. Nello specifico lautenticazionebasicsi articola nelle seguenti fasi:

il clienteffettua una richiesta ad un server;

ilserverrisponde con lheaderWWW-Authenticate contenente ilrealm;

il client richiede le informazioni di autorizzazione;

ilclientcrea una nuova richiestaGET nella quale fornisce le informazionidi autenticazione codificate inBase64(vd.3.5.4);

20Lattributo realm (case insensitive) richiesto per tutte quelle forme di autenticazioneche richiedano il cosiddetto challenge (protocolli basati su domanda - risposta). Il valoredel realm (case sensitive) definisce lo spazio di protezione. Lutilit dei realm consiste nellapossibilit di partizionare le risorse su un serverin tanti sottoinsiemi ciascuno dotato di proprimeccanismi di autenticazione. Il valore del realm una stringa, assegnata, generalmente,dallorigin server.

36


37/79

il browsercontinuer ad inviare il medesimo headerper tutte le pagine

dello stesso realm.Non esistono parametri di autenticazione opzionali.Il problema principale di tale approccio che la passwordtransita in chiaro

sulla rete. (Fig.20)

Figura 20: Esempio dichallengecon basic authentication

Digest access authentication E un meccanismo di autenticazione intro-dotto in HTTP 1.1. La caratteristica innovativa di tale approccio che la pas-

swordnon transita in chiaro bens mediante una fingerprint (hash), calcolataapplicando lalgoritmo di criptazione MD5 (Message Digest 5).Per evitare labuso dellapassword, anche se crittografata, insieme alla finger-

printvengono codificate anche informazioni, come lousername, il realm, lURIrichiesto, 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 singolaconnessione TCP per ciascun oggetto da trasferire. Si tratta, quindi, di connes-sioni non persistenti (Fig. 22). Un clientpu chiedere luso di connessionepersistente con lheader field Connection: Keep-alive: se ilserver supportale connessioni persistenti, inserir il medesimoheader fieldnella risposta.

37


38/79

Figura 21: Esempio dichallenge

con digest authentication

3.6.2 HTTP 1.1

In HTTP 1.1 per impostazione predefinita, le connessioni sono persisten-ti(Fig.22). Se ilserverdecide di chiudere la connessione, nella risposta inserirlheader field Connection: Close. Sia i server sia i client adottano timeoutdopo i quali le connessioni aperte, rimaste inattive, vengono chiuse.

Figura 22: Esempio di connessione non persistente (multiple connection) epersistente

Pipelining Il pipelining la trasmissione di pi richieste senza attenderelarrivo della risposta alle richieste precedenti (Fig. 23). Riduce ulteriormentei tempi di latenza, ottimizzando il traffico di rete, soprattutto per richieste cheriguardano risorse molto diverse fra loro per dimensioni o tempi di elaborazione.

E fondamentale che le risposte vengano date nello stesso ordine in cui sonostate fatte le richieste poich HTTP non fornisce un meccanismo esplicito diassociazione o riordinamento.

38


39/79

Figura 23: Esempio di connessione no pipeliningepipelining

3.7 Gestione delle sessioni

HTTP stateless: non ha memoria della precedente richiesta. In alcuni tipidi siti/applicazioni Web, tuttavia, necessario mantenere traccia delle richiesteprecedenti al fine di creare una transazione o sessione utente, cio un intervallodi tempo in cui un medesimo utente effettua una sequenza di accessi a risorsedi una determinata sezione del sito. In tali casi si deve ricorrere ad alcunetecnologie per tener traccia della sessione; un esempio dato dai cookie.

3.7.1 Cookie

Uncookie una breve informazione scambiata tra il servered il client(Fig.24).Il termine cookie (anche magic cookie) in informatica indica un blocco di datiopaco(cionon interpretabile) lasciato in consegna ad un richiedente per poterristabilire in seguito il suo diritto alla risorsa richiesta (come il tagliando di unalavanderia).

Si tratta di un piccolo file di testo locale esterno rispetto al paradigma diHTTP adoperata come estensione di Netscape nellRFC 2109 e poi ancora nelRFC 2965.

Il cookie identifica una sessione in corso (o uno stesso utente attraversoconnessioni successive).

Architettura di un cookie Alla prima richiesta di unouser-agent, il server

fornisce la risposta ed un headeraggiuntivo, il cookie, con dati arbitrari, e conla specifica di usarlo per ogni successiva richiesta.

Il server associa questi dati ad informazioni sulla transazione. Ogni volta chelo user-agentacceder a questo sito, rifornir i dati del cookieche permettonoal serverdi identificare nuovamente il richiedente.

Questioni di sicurezza permettono di distinguere tra:

cookiespediti solo alserverdi appartenenza, adoperati per sessioni, tran-sazioni e profilazione utenti;

cookiedi terze parti, usati per la profilazione utenti da networkpubblici-tari.

39


40/79

Icookieusano dueheader, uno per la risposta ed uno per le richieste succes-

sive: set-Cookie, headerdella risposta da parte di un server. Il client pu

memorizzarlo in un file testuale e rispedirlo alla prossima richiesta;

cookie, headerdella richiesta. Il clientdecide se spedirlo sulla base di:

URL della risorsa;

nome del server;

et del cookie.

Figura 24: Esempio di cookie

Alternative ai cookie I cookiepermettono al serverdi riassociare una ri-chiesta a richieste precedenti (creare uno stato tra connessioni) attraverso lusodi un pacchetto di dati opaco.

Ci sono altri metodi, ma hanno tutti difetti:

si potrebbe associare lo stato allindirizzo IP del richiedente ma alcunicomputer sono multi-utente, quindi utenti diversi condividono lo stessoIP; altri computer hanno indirizzi dinamici, e lo stesso IP pu essereassegnato a computer diversi;

si potrebbero nascondere informazioni allinterno della pagina HTML (at-traverso campi nascosti di un form), ma questo significa dover generaredinamicamente tutte le pagine ed essere soggetti a manipolazioni semplicida parte degli utenti. Inoltre sono informazioni che rimangono associatead una pagina specifica (unbacke ho perso il contenuto del mio carrello) ;

si potrebbero complicare gli URL della pagine, inserendo dentro le infor-mazioni di stato, ma si complica la gestione dei proxy, delle cache, e sirende pi facilmente manipolabile la stringa opaca.

40


41/79

Third - Party Cookies Un uso subdolo (ma alcuni lo giustificano) deicookie

linserimento nei banner e nelle pubblicit. Questo permette al fornitore dipubblicit viaWebdi seguire la navigazione di un utente attraverso tutti i siti acui forniscebanner, e quindi fornire una profilazione pi precisa del navigatore,con effetti discutibili sulla sua privacy. LRFC 2965 esplicitamente proibiscequesto tipo di comportamento, lavvertenza per largamente ignorata. Siaggiunga che alc

Linguaggi e tecnologie per il Web

Documents

Transcript of Linguaggi e tecnologie per il Web